cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Reinhard Poetz" <reinh...@apache.org>
Subject RE: Flowscript problem?
Date Fri, 26 Sep 2003 08:37:10 GMT

> From: Sylvain Wallez
> 
> 
> Reinhard Poetz wrote:
> 
> >>From: Christopher Oliver
> >>
> >>Reinhard,
> >>
> >>Try your calculator example again:
> >>
> >>This time enter values for both "a" and "b". Then clone the window, 
> >>hit the back button and enter a new value for "b". Return 
> to the first 
> >>window and submit it. You should see the new value of "b" 
> you set in 
> >>the second window. This is the expected behavior.
> >>
> >>I believe the reason your example did not work is that the 
> page where 
> >>you submit "a" does not involve an existing continuation 
> (it calls the top-level "calculator" function).
> >>    
> >>
> >
> >Thanks Chris, now I understand: as long as I'm in the same 
> function all 
> >variables are shared. If I call the function again (this 
> happens if you 
> >go back to the first page where you have to enter A), local 
> variables 
> >are only valid for this track.
> >
> >Sylvain described this behaviour very well
> >(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=10559305412
> 2167&w=2):
> >
> ><snip>
> >"Forking can mention both scenarios. In the case of a new 
> >flow-interaction, there's no sharing of local variables. In 
> the middle 
> >of a flow scenario, variables declared before the fork will 
> have their values shared between continuations, while 
> variables declared after will have a different value in each 
> branch. So yes, a local variable can be shared between 
> several continuation branches (fork within a flow scenario). 
> If this is not liked (because of the application specs), then 
> new variables should be created between the different 
> creation of continuations (i.e. between calls to 
> sendPageAndWait). </snip>
> >  
> >
> 
> Wow, I forgot I wrote this. Thanks for digging the archives, 
> Reinhard ;-)
> 
> I was also thinking about having ContinuationLocal variables 
> that would 
> mimic the behaviour of InheritableThreadLocal
> for continuations.
> 
> This would handle the use cases where a variable's value 
> should not be 
> shared between continuations : when the value is fetched, 
> crawl up the 
> continuation tree up to a point where a value exists, and 
> when the value 
> is set, attach it only to the forthcoming continuation (not to the 
> latest one, as it may be the root of a continuation subtree).

Sounds good! This would be the feature Francis is asking for, wouldn't
it?

Cheers,
Reinhard


Mime
View raw message