cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [Flow] Scope and Sessions
Date Wed, 18 Jun 2003 10:02:14 GMT
Marc Portier wrote:

> Sylvain Wallez wrote:
>> Geissel, Adrian wrote:
>>> Just a thought:
>>>>> From a technical point of view, are there any other possiblities 
>>>>> of implementing the JavaScript global scope.     
>>>> I assume this is a question. The request is obviously not good at this
>>>> and the servlet context is way too broad. Any other mechanism would 
>>>> be a
>>>> data container associated in some way to the state of the webapp
>>>> execution and this is exactly what a session is.
>>> Pier described a very good use-case which applies to pretty much every
>>> real-world web application - that basically it is understood to 
>>> re-entrant.
>>> From my experience, storing state in the session has two issues - 
>>> first is
>>> the 'forked UI syndrome' described, and the second is that resources
>>> associated with the state are held indefinitely, especially if the user
>>> decides not to complete the operation, as is their choice.
>>> My solution in the past has been to manage state / flow in the 
>>> response (ie.
>>> that sent back to the user), but obviously this is what Flow is 
>>> trying to
>>> improve.
>>> So, my thought is this - can the flow state be included in the 
>>> response for
>>> re-submission later. For example, a flow-invoked HTML serializer could
>>> insert hidden input fields to maintain state, or similar? 
>> Mmmh... don't take it as an offense, but I think you missed what is 
>> brought by continuations.
> might be the same over here, hope you can explain again since I'm 
> still failing to understand somewhat
>> The global context, attached to the session, should be used to store 
> with global context you mean?
> guessing: variables declared in the flow javascript but put outside 
> functions? 

Yep. Global context is the set of global variables (outside functions), 
opposed to local variables (inside functions).

>> values that don't depend on the current interaction flow. These will 
>> be mainly the user credentials, and any singleton values attached to 
>> the user (can be a shopping cart for example).
>> Transient state, describing the current interaction with the user, 
>> should be held by local variables in the flow function that drives this 
> but those are, if I got it right, not frozen inside the continuation, 
> but rather pointed to by reference? 

Yep again. So if a variable created by a given continuation is modified 
several continuations later and then you go back, the value is not 
"undoed", but keeps its modified value.

>> interaction. This means that they're attached not to the session, but 
>> to the continuation, and therefore can have different values if the 
>> UI is forked.
> so with forking, I assume you mean the creation of a new 
> flow-interaction? (and not forking by opening another window in the 
> middle of a flow-scenario or branching the continuations with the 
> back-button-take-other-path) 

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

>> So the flow state is transmitted through a single value, the 
>> continuation identifier, which can be either in a hidden field or in 
>> the submit URI.
> so the different continuation identifiers of a certain interaction 
> scenario all point to
> - their own execution-position in the flow-function 


> - the same variables (and thus state?) 

Variables defined within a continuation are shared by all its children, 
but not its ancestors nor siblings.

> and can additionally have access to the 'global space' which is 
> session and thus user-agent-tied?



Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message