On Fri, 12 Apr 2002 14:17:52 +0200, =?US-ASCII?Q?Daniel_Fagerstrom?= <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] 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 app. 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 "http://www.foo.com/addToCart.html?prodNo=123456"; > that call a flowmap function <map:call function="addToCart"/> and > "http://www.foo.com/checkOut.html"; 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 anywhere. 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 applications. 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 want. 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]
