cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <>
Subject Re: SV: continuation fear (was Re: [status & RT] design challenges)
Date Sat, 13 Apr 2002 10:45:42 GMT
On Fri, 12 Apr 2002 14:17:52 +0200, =?US-ASCII?Q?Daniel_Fagerstrom?= <>

> wrote:
> > Now to answer your question about going back in the history and
> > choosing a different path. Notice that the 'cart' instance variable
> > uses a shared Java HashMap instance. This means the same instance is
> > available to all the continuations, and any modification to it is
> > visible from the other continuations. This means that if you go back
> > and modify something in the page #2, the result will affect the cart
> > in page #12.
> >
> > If you want to consider that once the user went back to page #2, s/he
> > has in the cart only the item he chose in page #1, you'd have to copy,
> > perhaps in a lazy fashion to avoid memory bloat, the 'cart' instance
> > variable. This way each page in the tree maintains its own copy of the
> > cart.
> <snip/>
> Thank you for your clarifying answer!
> Let, see if I get it right: for traditional webapps like a shopping site you
> are updating global variables, shoping cart, adress info and so on. For
> "what if" scenarious you use local variables, and creates the possiblity to
> "undo" things by creating new stack frames, i.e. by going into a new block
> or calling a function.
> IIUC, in the shopping site example above we are in effect only using the
> application global variable "shopper", the local variables are transient and
> could be optimized away from the saved continuations with a clever
> implementation. As a result the continuation objects only need to contain a
> pointer to the "global" variables and a stack of program counters. The stack
> of program counters could furthermore be optimized away I belive, in the
> above example by using tail recursion optimization and by "inline expansion"
> of some of the functions. In the scenario we also need a mechanism for
> preventing (or at least warn) the user from reloading the page that
> excecutes <map:call function="startShopping"/> as this would lead to several
> independent shopping sessions, which might be highly confusing.
> Thinking more about the shopping example I think I would like to inverse the
> control between the sitemap and the flowmap: After all, the "shopping
> around" part of the story is mainly web-publishing. There is a large
> database of products that are to be presented, there is a search engine and
> the access patterns are unstructured rather than linear. All this seem like
> the tasks where the sitemap excel. Embedded in the pages we might have an
> overview of the items in the shopping cart, personalized recomendations,
> links to earlier visited product pages and so on, but this  seem still to be
> information of global character that would easily be presentable with
> publishing oriented concepts, already implemented in Cocoon.

Yes, but the web-publishing part involves doing a lot of business
logic. The control flow layer not only proposes a way to manage
complex flow, but also proposes an MVC paradigm for developing a Web

Instead of putting the business logic in an XSP page, you do it
instead in Java. The linkage between the page generation and the
business logic is done through the flow layer, which acts as the
Controller between the business logic and the page generation.

One of the powerful things about the flow layer is that you can invoke
some glue code, quickly put together in JavaScript. This accesses the
Java code that calls your backend database, and creates the necessary
data to be presented in your pages. It then passes this data down to
the View layer. It can do this without having to maintain any
continuation object. A specialized sendPage(), lets say
sendPageDontStop() can be written, which doesn't create a
continuation. In fact sendPage() is nothing but a wrapper around the
Cocoon sitemap invocation, plus the code to create a
continuation. It's trivial to come up with the non-continuation based
sendPage() function.

The MVC model is achieved in a JSP world (Struts included) by putting
the Controller code in a servlet. Probably this can be done with
Cocoon as well, I've never seen it done before. As a result we are
somehow forced to use a very page centric programming paradigm when
developing Web apps.

> IMO the role for a flowmap is to take care of structured interactions
> (wizards) and in the shopping case, examples of such are: checking out,
> editing the shopping cart and uppdating your preferences. So, on a product
> page there are links like ""
> that call a flowmap function <map:call function="addToCart"/> and
> "" that call <map:call function="
> checkOut"/> and so on. These flowmap functions all works on application
> global variables, and takes care of structured user interaction.

Right, and the addToCart() and checkOut() functions called from the
sitemap can update the session object. They eventually call the
sendPageDontStop() to generate the output page, passing to it the data
objects which are needed to be displayed. No continuation is saved

So your shopping application would have entries in the sitemap to call
all these action functions in the control flow layer. They invoke the
business logic and pass appropriate objects again to the sitemap for
page generation. No XSPs or any other page oriented programming, which
makes maintaining and extending the code very difficult IMO.

> This far in the discussion one might start to get the herretic thought: Ok,
> handling "what if" scenarious is really cool, but is it worth the effort of
> saving all the stack frames? Isn't uppdating the old, boring and global
> session attributes, when thinking about it, a rather good model of what a
> user might expect to experience from e.g. a shopping site?
> To conclude: I believe that using continuations is a good idea as it allows
> us to use control flow concepts from structured programming in our flowmaps:
> sequence, choice and repetition. The question is: how much should we store
> in the continuation? If we only use a program pointer we can use basic
> control flow together with global variables, storing the call stack (a stack
> of program pointers) we can use (possibly recursive) functions, and by
> storing all the stack frame, local variables and thus "what if" scenarios
> become possible.
> Before having seen some "must have" real world use cases for "what if"
> scenarios, I tend to think that just storing the call stack would be more
> than enough in a flowmap language.
> What do you think?

Storing variable values is part of a continuation, and we cannot and
shouldn't modify this behavior.

The value of continuations based flow programming is not only in "what
if" scenarios; this is only an application of it. As you mention
above, the real value is that it allows you to manage the order in
which pages get generated in a really nice, programmatic way.


The control flow layer brings much more to Cocoon than a new
programming model for the flow. It introduces the MVC paradigm in a
nice way, which IMO is a great methodology for developing large

With the control flow layer you can write applications that combine
the continuations based flow, with the ability to invoke functions
that glue the business logic with the page generation, in any way you

Ovidiu Predescu <> (GNU, Emacs, other stuff)

To unsubscribe, e-mail:
For additional commands, email:

View raw message