> On Tue, 26 Feb 2002 19:07:20 +0300, "Piroumian, Konstantin"
<[EMAIL PROTECTED]> wrote:
>
> > > As to using a "Component" to do the work, we already have the proper
> > > granularity. I.e. Schecoon. Currently we have Actions to help
control
> > > flow, and we have Matchers and Selectors.
> >
> > Yes, that's true. We've been using actions to interact with the flow
> > controller. So, why do we need another language to describe the flow?
Why
> > not Java?
>
> Because Java doesn't have support for continuations.
>
> A continuation is a way to represent what is the processing that still
> needs to happen. Think of a continuation as an object that, for a
> given point in your program, contains a snapshot of the stack trace,
> including all the local variables, and the program counter. You can
> not only store these things in the continuation object, but also
> restore the execution of the program from a continuation object. This
> means that the stack trace and the program counter of the running
> program become the ones stored in a continuation.
>
> By resuming the processing stored by a continuation object, you
> essentially resume the program from the point it was stopped. This
> allows you to write programs that do something like this:
>
>
> // some processing going here
> ...
> -> send-page("response.xml");
> ...
> // some other processing here
> ...
>
> With continuations in the language, you can essentially store the
> continuation of send-page (think of all the stack trace, and the
> program counter), put it in a global hash table associated with an
> id. The id is then encoded in the response.xml page as an URL. When
> the user clicks on that URL, on the server side the associated
> continuation is resumed. Resuming the processing happens as if nothing
> was stopped, you get all the stack trace back, and all the local
> variables.
>
> So instead of using beans to store things in session, you use normal
> variables in a program. Since each user has its own version of the
> program, all the local variables in the program are separate between
> users.
>
> With this approach clicking the "Back" button in the browser is no
> longer a hassle to deal with for you as a server-side programmer. They
> will simply refer to past continuations objects, which have their own
> state of the local variables.
>
> Since continuations are objects, you can also store them in a
> database, for really long-lived session, just like you do with session
> beans.
Thanks for a wonderful lecture. Now I understand why Scheme language is used
and why people love/will love it. But all that is possible with other means
too, although it will require implementing something similar to
continuations concept. (We have something like that, see my response to
Berin's critics).
Anyway, continuations concept is a great idea and I'm going to like it ;)
>
> > It will only make Cocoon more frightening to new people.
>
> I don't think so, on the contrary, I think it will change the way you
> think about Web applications.
Mine - yes. But the people who are new to Cocoon would be scared with the
plenty of things that they should learn to use Cocoon. (It's not only
theory. I've been trying to convience people that used JSP/custom templates
for a long time to look at Cocoon but with a little success. Most of the
people don't like learning new things, especially when they feel comfortable
with their current tools and technologies).
>
> > I'm not a newbie in Cocoon, but even I am tired of revolutionary
> > changes in it (C1 - C2 - .. - [C2 + Schecoon - Actions]), lack of
> > documentation, etc. and it's going to be very hard to convience
> > other people even to try it.
>
> I actually like changes, even though a really good friend of mine
> keeps saying "change is bad" ;-) They make the life more exciting, if
> properly plan for them.
>
I prefer evolutionary but not revolutionary changes. After I've been
migrating our application from C1 to C2 I started to hate changes ;)
Btw, because of difficulties and required too much time to migrate from C1
to C2 our project architects decided to switch to a more standard and stable
technology, like JSP (and Struts). That's why we don't use Cocoon anymore. I
think that our case is not unique.
> > >
> > > Schecoon was started as they do not represent intuitive and useful
> > > control layers for a webapp. That is why the Avalon Component thing
> > > isn't going forward any farther than it already has.
> >
> > Do you think that Schecoon is more intuitive? It's just another
programming
> > language.
>
> Right, is a programming language but with a very powerful paradigm,
> that no other language you've used before has. As I said earlier, it
> is my belief that this has the potential to change the way you do Web
> applications.
>
> > > Also, the full Java language is too difficult to express in a simple
> > > script environment. What about using JavaScript? You only have to
> > > support certain models, and many web programmers are familiar with it.
> >
> > Can JS provide means to call business logic from it? Simple cases
> > are easily expressed in XML-based script. (I would send you a real
> > sample, but it's prohibited in our company).
>
> Schecoon will definitely provide this integration between the business
> logic layer, flow and content generation/presentation.
That's fine.
>
> > > All we need to do is provide a bridge for Scheme continuations to the
> > > JavaScript interpreter engine....
> >
> > I'm not familiar with continuations, will look at them when there will
be a
> > sample for Scheme.
>
> I hope the description I gave above provides a gentle enough
> introduction to continuations.
Yes, it was quite clear. It worth at least to be placed in a readme file in
Schecoon directory.
>
> > > > I've been also thinking about adding extension mechanism
> > > > (something like transformers/logicsheets) that would allow to
> > > > add custom handlers to our flow script and an idea came to me:
> > > > maybe flow controll can be plugged > to Cocoon using sitemap
> > > > logicsheets? In that case nothing is changed in > Cocoon core
> > > > and everybody can have the flow controller he needs/likes.
> > > >
> > > > Just my <i18n:currency value="0.02" />
> > >
> > > We currently have the ability to choose our Sitemap implemenation
> > > directly. Whether we choose the original sitemap layout, or we mount
a
> > > flowmap directly in its place doesn't matter. All that matters is
that
> > > requests go in and responses go out.
> >
> > I would like to have a possibility to choose the flowmap implementation
and
> > not the whole sitemap. Current sitemap is quite good for me to implement
> > anything I need and the only thing to improve is action/action-sets and
> > cleanup/stabilize the syntax. This is my opinion.
>
> Schecoon will not preclude you from using the concepts so familiar to
> you today. Schecoon is yet another sitemap implementation, which you
> can mount from either the compiled or interpreted versions. If you
> don't need flow control, you don't need to use it. But as you become
> familiar with it, you will be able to switch back and forth between
> implementations.
Ok. I'll look at it when there will be a sample.
Thank you for your time.
Regards,
Konstantin
>
> Best regards,
> --
> Ovidiu Predescu <[EMAIL PROTECTED]>
> http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other
stuff)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
