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?
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?
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)
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?)
and can additionally have access to the 'global space' which is session and thus user-agent-tied?
Hope this helps.
Sylvain
-marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
