> 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
