cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <ovi...@cup.hp.com>
Subject Re: [Schecoon] flow control layer
Date Wed, 27 Feb 2002 03:46:53 GMT
On Tue, 26 Feb 2002 19:07:20 +0300, "Piroumian, Konstantin" <KPiroumian@flagship.ru>
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.

> 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.

> 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.

> >
> > 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.

> > 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.

> > > 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.

Best regards,
-- 
Ovidiu Predescu <ovidiu@cup.hp.com>
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message