Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 90665 invoked by uid 500); 20 May 2003 08:29:55 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 90651 invoked from network); 20 May 2003 08:29:54 -0000 Received: from smtp1.xs4all.be (195.144.64.135) by daedalus.apache.org with SMTP; 20 May 2003 08:29:54 -0000 Received: from outerthought.org (stat88-18.adsl.xs4all.be [195.144.88.18]) by smtp1.xs4all.be (8.12.9/8.12.9) with ESMTP id h4K8U6hY001690 for ; Tue, 20 May 2003 10:30:06 +0200 Message-ID: <3EC9E78D.8080703@outerthought.org> Date: Tue, 20 May 2003 10:30:05 +0200 From: Marc Portier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en, nl-be MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: SoC between flow and sitemap References:

<3EC800C3.3040901@anyware-tech.com> <3EC931D1.2060906@outerthought.org> <3EC948F5.9050604@anyware-tech.com> In-Reply-To: <3EC948F5.9050604@anyware-tech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Sylvain Wallez wrote: > Marc Portier wrote: >> Stefano Mazzocchi wrote: >>> on 5/18/03 4:53 PM Sylvain Wallez wrote: >>> >>>> This is only one of the reasons why fetching the continuation ID >>>> cannot be hardcoded. Another example is the XMLForm integration with >>>> the flow (yep, one more nice thing by Christopher!), where a single >>>> page holds 2 continuations ID : the current one associated to >>>> "next", and a previous one associated to "prev". >>> >>> Yes. I remember discussing this IRL with Ugo a while back where he >>> was exactly complaining about the fact that a "back" button >>> associated with the previous continuation would simply make us fall >>> back in the same screen we are, not in the previous one. And jumping >>> back by two continuations will re-execute the logic between the two >>> previous screens (which is not always desirable). Glad to see that >>> fixed (I haven't tried it yet) >>> >>> Note: wouldn't it be better to store one continuation ID, then add >>> the "history" of continuations to the Continuation object that we >>> retrieve with that ID? >>> >> >> which would make things look more like the approach I was mentioning >> >> one id that points to the complete interaction, and in there possible >> addressable sub-resources >> >> also, I find the ability to link to back and previous rather dull (in >> fact I would of hoped that flow was the thing that worked out the >> browser back button?) in real life I would see not only the old-style >> wizard back/next/finish buttons but actually some random navigation >> back to any previous screen you had in this interaction... > > > > It also works that way, and continuations have reference to their parent > continuation (see o.a.c.c.flow.WebContinuation). > yep, what I added to the show is that it might be nice to introduce logical names (labels?) to any of those patricular states, so that we can have instead of {continuation.id} the ability to point to {flow.next} and {flow.back} as easy as pointing to {flow.start} {flow.configuration-step} based on logical sub-steps in the use case people would like to link back (in stead of requiring your user to back-back-back) >>> >>> Ricardo and I discussed extensively about this and started >>> challenging the notion of continuations without sessions. Is there a >>> real-life reason for them? >> >> sessions are limited in the sense that they have the habbit of making >> 'singeltons' per session of the objects you store in there... sessions >> are also tied to a single end-user >> >> so using sessions limits you. >> >> while you often may want that, it doesn't seem to be a general case to >> me. > > Continuations allow different behaviours : as local variables are bound > to the continuation (and not the session), a flow script using only mmm, in fact when I did the Tony Collen guess game I noticed the opposite: - I did the game and used say 4 tries to guess the number (say 2) - I do back-back-back and enter number 2 as my 1st guess :-) - indeed I am right, but the page shows it was my 5th try we might see this is the computer knew that I was trying to cheat, but I saw the variable as beingin my session, which is not what I would of expected (or want in some case) > local variables avoids this singleton limitation. You can use global > script variables (bound to the session) for items that really are > singletons in the user space, such as user name and credentials. > I hear you saying that it can be done? I missed out on that then, care to share how to do it? (checking the game on the wiki again: the var guess is local to the main script!) >> not sure if I understand all depths yet, but it seems to limit me >> quite a bit > > The only limit it gives is that you won't be able to share continuations > between sessions. A use of data shared between sessions is your example > of call center, but I'm not sure implementing this by sharing > continuations is a good thing, since a continuation not only represents > a resource state, but a program state. yep, totaly agree here that's basically why I see our alternative as being distinct from flow (it serves a different class of problems) > > Sylvain > regards, -marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ mpo@outerthought.org mpo@apache.org