cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: SoC between flow and sitemap
Date Tue, 20 May 2003 08:30:05 GMT

Sylvain Wallez wrote:
> Marc Portier wrote:
>> Stefano Mazzocchi wrote:
>>> on 5/18/03 4:53 PM Sylvain Wallez wrote:

<snip />

>>>> 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 {} the 
ability to point to {} 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)

<snip />

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

- 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!)

<split />

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

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message