Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
From: "Francis Vermeulen" <fvermeulen@ezgov.com>
To: <users@cocoon.apache.org>
Subject: RE: Flowscript problem?
Date: Mon, 29 Sep 2003 09:10:21 +0200
Message-ID: <IOEIKBOJBLFADNAJJBILAEJACAAA.fvermeulen@ezgov.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <3F7463ED.7090006@verizon.net>
Disposition-Notification-To: "Francis Vermeulen" <fvermeulen@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