You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2003/09/25 22:17:35 UTC
RE: Flowscript problem?
Chris,
> From: Christopher Oliver
>
> Local variables are _shared_ between continuations. Changes
> to the value
> of the variable in one continuation should be visible to another. If
> that is not the case, there's a bug.
Try the calculator example as desribed below. But I'm not sure if this
is a bug. IIRC this is not the first time we discuss this but I only
found one pointer:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105593054122167&w=2
Does anybody find more on this subject?
Reinhard
P.S.: Moving again a discussion to the dev list
>
> Chris
>
> Reinhard Poetz wrote:
>
> >>From: Francis Vermeulen
> >>
> >>thanks for the reply. But as I understood it, for a single
> >>script there may be multiple continuations at any point in
> >>time, all corresponding to different page submissions so that
> >>if you use the browser back button, submitting that page can
> >>use that particular continuation to restore the intepreter
> >>state as it was when that page was being submitted the first
> >>time.
> >>
> >>
> >
> >sorry, my last answer was too fast: you are right, local
> variables are
> >bound to the continuation. I tried it with the calculator example by
> >changing all variables to local variables. I entered a and b
> and then
> >forked my browser window (using IE with Ctrl+N) and jumped back to
> >enter a different value for b. If I used local variables I got two
> >different results which is the right behaviour. I tested with a CVS
> >snapshot from last week (with the latest rhino lib).
> >
> >
> >
> >>That's even the example given in the documentation? So
> >>I don't understand your point, I'm sorry. Can you clarify
> >>further on this?
> >>
> >>
> >
> >Sorry again.
> >
> >Try out the calculator examples the way I did. Do you get the same
> >results as I got?
> >
> >Cheers,
> >Reinhard
ContinuationLocal (was Re: Flowscript problem?)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Reinhard Poetz wrote:
>From: Sylvain Wallez
>
>
>>>>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?
>>>
>>>
>>Yes, and it would allow to "pay the cost" for this behaviour only when it's really needed.
>>
>>
>
>Do you already have an idea how to implement this? This means digging
>into rhino-continuations, doesn't it?
>
I wasn't thinking of implementing this so deeply in the language, since
it would require an additional keyword in place of "var"
("continuation_var" or "transient var" ?).
If we follow the ThrealLocal example, this is just a regular class. And
its implementation would impact only (as far as I can say now) the
continuation stuff in Cooon.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
RE: Flowscript problem?
Posted by Reinhard Poetz <re...@apache.org>.
From: Sylvain Wallez
> >>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?
> >
> >
>
> Yes, and it would allow to "pay the cost" for this behaviour
> only when
> it's really needed.
Do you already have an idea how to implement this? This means digging
into rhino-continuations, doesn't it?
Reinhard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Flowscript problem?
Posted by Reinhard Poetz <re...@apache.org>.
From: Sylvain Wallez
> >>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?
> >
> >
>
> Yes, and it would allow to "pay the cost" for this behaviour
> only when
> it's really needed.
Do you already have an idea how to implement this? This means digging
into rhino-continuations, doesn't it?
Reinhard
Re: Flowscript problem?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Reinhard Poetz wrote:
>>From: Sylvain Wallez
>>
>>
<snip/>
>>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?
>
>
Yes, and it would allow to "pay the cost" for this behaviour only when
it's really needed.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Flowscript problem?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Reinhard Poetz wrote:
>>From: Sylvain Wallez
>>
>>
<snip/>
>>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?
>
>
Yes, and it would allow to "pay the cost" for this behaviour only when
it's really needed.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
RE: Flowscript problem?
Posted by Reinhard Poetz <re...@apache.org>.
> 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
RE: Flowscript problem?
Posted by Reinhard Poetz <re...@apache.org>.
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Flowscript problem?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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=105593054122167&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).
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Flowscript problem?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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=105593054122167&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).
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
RE: Flowscript problem?
Posted by Reinhard Poetz <re...@apache.org>.
> 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=105593054122167&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>
Cheers,
Reinhard
RE: Flowscript problem?
Posted by Francis Vermeulen <fv...@ezgov.com>.
Chris,
this is the Cocoon documentation page I was referring too:
http://localhost:8888/docs/userdocs/advanced/flow/how-does-it-work.html
I hope you will agree that the wording suggests that local variables are NOT
shared by continuations. And too me that would seem more logical too,
because then handling the browser "back" button is just a matter of
restoring the appropriate continuation and the whole application (including
the controller) is back in the same state as when that page was originally
submitted. Now, I have been reading through the literature and I admit that
all articles suggest that local variables are shared, so from that point of
view, the Cocoon implementation is correct. Hence, I've coded an explicit
back button handling in my flow script: I detect the use of the back button
by including a page identifier in each page and comparing that identifier to
what the application thinks is the current page.
Regards,
Francis
-----Original Message-----
From: Christopher Oliver [mailto:res1cf5x@verizon.net]
Sent: Friday, September 26, 2003 6:06 PM
To: users@cocoon.apache.org
Subject: Re: Flowscript problem?
Please show me where the behavior you describe is documented. AFAIK
that's not the case. As in Scheme, JavaScript continuations share local
variables. Changes in one continuation are reflected in others that
share the same stack frames. What is restored when you click on the back
button is the program counter, so that your web app continues processing
at the correct location associated with the submitted page. Because of
this continuations are lightweight, both in terms of memory and
processing time.
Regards,
Chris
Francis Vermeulen wrote:
>Christopher,
>
>thanks for the explanation: what you describe is exactly what I'm seeing.
>However, whether this is the desired behaviour, I'm not sure. If I want the
>flow script to handle the browser back button transparently, I'd expect my
>script state to be restored exactly the way it was when that page was
>originally submitted, including the stack which includes the local
>variables. This is also how it is described in the flow script
documentation
>btw. The net result of the way it behaves now is that when I go back to an
>earlier page, the script doesn't behave as it should since its local
>variables are not correctly restored.
>
>Regards,
>Francis
>
>-----Original Message-----
>From: Christopher Oliver [mailto:res1cf5x@verizon.net]
>Sent: Friday, September 26, 2003 5:45 AM
>To: dev@cocoon.apache.org
>Cc: users@cocoon.apache.org
>Subject: Re: Flowscript problem?
>
>
>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).
>
>Regards,
>
>Chris
>
>Reinhard Poetz wrote:
>
>
>
>>Chris,
>>
>>
>>
>>
>>
>>>From: Christopher Oliver
>>>
>>>Local variables are _shared_ between continuations. Changes
>>>to the value
>>>of the variable in one continuation should be visible to another. If
>>>that is not the case, there's a bug.
>>>
>>>
>>>
>>>
>>Try the calculator example as desribed below. But I'm not sure if this
>>is a bug. IIRC this is not the first time we discuss this but I only
>>found one pointer:
>>http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105593054122167&w=2
>>Does anybody find more on this subject?
>>
>>Reinhard
>>
>>P.S.: Moving again a discussion to the dev list
>>
>>
>>
>>
>>
>>>Chris
>>>
>>>Reinhard Poetz wrote:
>>>
>>>
>>>
>>>
>>>
>>>>>From: Francis Vermeulen
>>>>>
>>>>>thanks for the reply. But as I understood it, for a single
>>>>>script there may be multiple continuations at any point in
>>>>>time, all corresponding to different page submissions so that
>>>>>if you use the browser back button, submitting that page can
>>>>>use that particular continuation to restore the intepreter
>>>>>state as it was when that page was being submitted the first
>>>>>time.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>sorry, my last answer was too fast: you are right, local
>>>>
>>>>
>>>>
>>>>
>>>variables are
>>>
>>>
>>>
>>>
>>>>bound to the continuation. I tried it with the calculator example by
>>>>changing all variables to local variables. I entered a and b
>>>>
>>>>
>>>>
>>>>
>>>and then
>>>
>>>
>>>
>>>
>>>>forked my browser window (using IE with Ctrl+N) and jumped back to
>>>>enter a different value for b. If I used local variables I got two
>>>>different results which is the right behaviour. I tested with a CVS
>>>>snapshot from last week (with the latest rhino lib).
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>That's even the example given in the documentation? So
>>>>>I don't understand your point, I'm sorry. Can you clarify
>>>>>further on this?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Sorry again.
>>>>
>>>>Try out the calculator examples the way I did. Do you get the same
>>>>results as I got?
>>>>
>>>>Cheers,
>>>>Reinhard
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Flowscript problem?
Posted by Christopher Oliver <re...@verizon.net>.
Please show me where the behavior you describe is documented. AFAIK
that's not the case. As in Scheme, JavaScript continuations share local
variables. Changes in one continuation are reflected in others that
share the same stack frames. What is restored when you click on the back
button is the program counter, so that your web app continues processing
at the correct location associated with the submitted page. Because of
this continuations are lightweight, both in terms of memory and
processing time.
Regards,
Chris
Francis Vermeulen wrote:
>Christopher,
>
>thanks for the explanation: what you describe is exactly what I'm seeing.
>However, whether this is the desired behaviour, I'm not sure. If I want the
>flow script to handle the browser back button transparently, I'd expect my
>script state to be restored exactly the way it was when that page was
>originally submitted, including the stack which includes the local
>variables. This is also how it is described in the flow script documentation
>btw. The net result of the way it behaves now is that when I go back to an
>earlier page, the script doesn't behave as it should since its local
>variables are not correctly restored.
>
>Regards,
>Francis
>
>-----Original Message-----
>From: Christopher Oliver [mailto:res1cf5x@verizon.net]
>Sent: Friday, September 26, 2003 5:45 AM
>To: dev@cocoon.apache.org
>Cc: users@cocoon.apache.org
>Subject: Re: Flowscript problem?
>
>
>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).
>
>Regards,
>
>Chris
>
>Reinhard Poetz wrote:
>
>
>
>>Chris,
>>
>>
>>
>>
>>
>>>From: Christopher Oliver
>>>
>>>Local variables are _shared_ between continuations. Changes
>>>to the value
>>>of the variable in one continuation should be visible to another. If
>>>that is not the case, there's a bug.
>>>
>>>
>>>
>>>
>>Try the calculator example as desribed below. But I'm not sure if this
>>is a bug. IIRC this is not the first time we discuss this but I only
>>found one pointer:
>>http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105593054122167&w=2
>>Does anybody find more on this subject?
>>
>>Reinhard
>>
>>P.S.: Moving again a discussion to the dev list
>>
>>
>>
>>
>>
>>>Chris
>>>
>>>Reinhard Poetz wrote:
>>>
>>>
>>>
>>>
>>>
>>>>>From: Francis Vermeulen
>>>>>
>>>>>thanks for the reply. But as I understood it, for a single
>>>>>script there may be multiple continuations at any point in
>>>>>time, all corresponding to different page submissions so that
>>>>>if you use the browser back button, submitting that page can
>>>>>use that particular continuation to restore the intepreter
>>>>>state as it was when that page was being submitted the first
>>>>>time.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>sorry, my last answer was too fast: you are right, local
>>>>
>>>>
>>>>
>>>>
>>>variables are
>>>
>>>
>>>
>>>
>>>>bound to the continuation. I tried it with the calculator example by
>>>>changing all variables to local variables. I entered a and b
>>>>
>>>>
>>>>
>>>>
>>>and then
>>>
>>>
>>>
>>>
>>>>forked my browser window (using IE with Ctrl+N) and jumped back to
>>>>enter a different value for b. If I used local variables I got two
>>>>different results which is the right behaviour. I tested with a CVS
>>>>snapshot from last week (with the latest rhino lib).
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>That's even the example given in the documentation? So
>>>>>I don't understand your point, I'm sorry. Can you clarify
>>>>>further on this?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Sorry again.
>>>>
>>>>Try out the calculator examples the way I did. Do you get the same
>>>>results as I got?
>>>>
>>>>Cheers,
>>>>Reinhard
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Flowscript problem?
Posted by Francis Vermeulen <fv...@ezgov.com>.
Christopher,
thanks for the explanation: what you describe is exactly what I'm seeing.
However, whether this is the desired behaviour, I'm not sure. If I want the
flow script to handle the browser back button transparently, I'd expect my
script state to be restored exactly the way it was when that page was
originally submitted, including the stack which includes the local
variables. This is also how it is described in the flow script documentation
btw. The net result of the way it behaves now is that when I go back to an
earlier page, the script doesn't behave as it should since its local
variables are not correctly restored.
Regards,
Francis
-----Original Message-----
From: Christopher Oliver [mailto:res1cf5x@verizon.net]
Sent: Friday, September 26, 2003 5:45 AM
To: dev@cocoon.apache.org
Cc: users@cocoon.apache.org
Subject: Re: Flowscript problem?
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).
Regards,
Chris
Reinhard Poetz wrote:
>Chris,
>
>
>
>>From: Christopher Oliver
>>
>>Local variables are _shared_ between continuations. Changes
>>to the value
>>of the variable in one continuation should be visible to another. If
>>that is not the case, there's a bug.
>>
>>
>
>Try the calculator example as desribed below. But I'm not sure if this
>is a bug. IIRC this is not the first time we discuss this but I only
>found one pointer:
>http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105593054122167&w=2
>Does anybody find more on this subject?
>
>Reinhard
>
>P.S.: Moving again a discussion to the dev list
>
>
>
>>Chris
>>
>>Reinhard Poetz wrote:
>>
>>
>>
>>>>From: Francis Vermeulen
>>>>
>>>>thanks for the reply. But as I understood it, for a single
>>>>script there may be multiple continuations at any point in
>>>>time, all corresponding to different page submissions so that
>>>>if you use the browser back button, submitting that page can
>>>>use that particular continuation to restore the intepreter
>>>>state as it was when that page was being submitted the first
>>>>time.
>>>>
>>>>
>>>>
>>>>
>>>sorry, my last answer was too fast: you are right, local
>>>
>>>
>>variables are
>>
>>
>>>bound to the continuation. I tried it with the calculator example by
>>>changing all variables to local variables. I entered a and b
>>>
>>>
>>and then
>>
>>
>>>forked my browser window (using IE with Ctrl+N) and jumped back to
>>>enter a different value for b. If I used local variables I got two
>>>different results which is the right behaviour. I tested with a CVS
>>>snapshot from last week (with the latest rhino lib).
>>>
>>>
>>>
>>>
>>>
>>>>That's even the example given in the documentation? So
>>>>I don't understand your point, I'm sorry. Can you clarify
>>>>further on this?
>>>>
>>>>
>>>>
>>>>
>>>Sorry again.
>>>
>>>Try out the calculator examples the way I did. Do you get the same
>>>results as I got?
>>>
>>>Cheers,
>>>Reinhard
>>>
>>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Flowscript problem?
Posted by Reinhard Poetz <re...@apache.org>.
> 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=105593054122167&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>
Cheers,
Reinhard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Flowscript problem?
Posted by Christopher Oliver <re...@verizon.net>.
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).
Regards,
Chris
Reinhard Poetz wrote:
>Chris,
>
>
>
>>From: Christopher Oliver
>>
>>Local variables are _shared_ between continuations. Changes
>>to the value
>>of the variable in one continuation should be visible to another. If
>>that is not the case, there's a bug.
>>
>>
>
>Try the calculator example as desribed below. But I'm not sure if this
>is a bug. IIRC this is not the first time we discuss this but I only
>found one pointer:
>http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105593054122167&w=2
>Does anybody find more on this subject?
>
>Reinhard
>
>P.S.: Moving again a discussion to the dev list
>
>
>
>>Chris
>>
>>Reinhard Poetz wrote:
>>
>>
>>
>>>>From: Francis Vermeulen
>>>>
>>>>thanks for the reply. But as I understood it, for a single
>>>>script there may be multiple continuations at any point in
>>>>time, all corresponding to different page submissions so that
>>>>if you use the browser back button, submitting that page can
>>>>use that particular continuation to restore the intepreter
>>>>state as it was when that page was being submitted the first
>>>>time.
>>>>
>>>>
>>>>
>>>>
>>>sorry, my last answer was too fast: you are right, local
>>>
>>>
>>variables are
>>
>>
>>>bound to the continuation. I tried it with the calculator example by
>>>changing all variables to local variables. I entered a and b
>>>
>>>
>>and then
>>
>>
>>>forked my browser window (using IE with Ctrl+N) and jumped back to
>>>enter a different value for b. If I used local variables I got two
>>>different results which is the right behaviour. I tested with a CVS
>>>snapshot from last week (with the latest rhino lib).
>>>
>>>
>>>
>>>
>>>
>>>>That's even the example given in the documentation? So
>>>>I don't understand your point, I'm sorry. Can you clarify
>>>>further on this?
>>>>
>>>>
>>>>
>>>>
>>>Sorry again.
>>>
>>>Try out the calculator examples the way I did. Do you get the same
>>>results as I got?
>>>
>>>Cheers,
>>>Reinhard
>>>
>>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Flowscript problem?
Posted by Christopher Oliver <re...@verizon.net>.
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).
Regards,
Chris
Reinhard Poetz wrote:
>Chris,
>
>
>
>>From: Christopher Oliver
>>
>>Local variables are _shared_ between continuations. Changes
>>to the value
>>of the variable in one continuation should be visible to another. If
>>that is not the case, there's a bug.
>>
>>
>
>Try the calculator example as desribed below. But I'm not sure if this
>is a bug. IIRC this is not the first time we discuss this but I only
>found one pointer:
>http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105593054122167&w=2
>Does anybody find more on this subject?
>
>Reinhard
>
>P.S.: Moving again a discussion to the dev list
>
>
>
>>Chris
>>
>>Reinhard Poetz wrote:
>>
>>
>>
>>>>From: Francis Vermeulen
>>>>
>>>>thanks for the reply. But as I understood it, for a single
>>>>script there may be multiple continuations at any point in
>>>>time, all corresponding to different page submissions so that
>>>>if you use the browser back button, submitting that page can
>>>>use that particular continuation to restore the intepreter
>>>>state as it was when that page was being submitted the first
>>>>time.
>>>>
>>>>
>>>>
>>>>
>>>sorry, my last answer was too fast: you are right, local
>>>
>>>
>>variables are
>>
>>
>>>bound to the continuation. I tried it with the calculator example by
>>>changing all variables to local variables. I entered a and b
>>>
>>>
>>and then
>>
>>
>>>forked my browser window (using IE with Ctrl+N) and jumped back to
>>>enter a different value for b. If I used local variables I got two
>>>different results which is the right behaviour. I tested with a CVS
>>>snapshot from last week (with the latest rhino lib).
>>>
>>>
>>>
>>>
>>>
>>>>That's even the example given in the documentation? So
>>>>I don't understand your point, I'm sorry. Can you clarify
>>>>further on this?
>>>>
>>>>
>>>>
>>>>
>>>Sorry again.
>>>
>>>Try out the calculator examples the way I did. Do you get the same
>>>results as I got?
>>>
>>>Cheers,
>>>Reinhard
>>>
>>>
>
>
>
>