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
Yep.
- 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?
Yep.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
