On Wednesday, June 18, 2003, at 12:51 AM, Pier Fumagalli wrote:
On 17/6/03 22:51, "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote:
- Should the flow _always_ be associated with a Session?
I haven't written a flowscript that didn't require, in some way or
another, the availability of some statefulness on data and it seems to
me as overkill to use full execution state preserving (and the
URI-encoding of the continuation every time!) just for the data
(besides, even today, if you want to keep global flow variables around,
you have to enable sessions anyway)
In general, it is true that continuations and sessions are different beasts, but in real life, continuations *extend* sessions since they provide the ability to save *even more* state than sessions.
But in those situations where procedular flow is weak and navigation
decisions are driven by user action and not by flow execution,
continuations are overkill and sessions are still the preferred way to go.
is there a real need for continuations without sessions? i really can't
provide a meaningful example of this.
so, I would say +1 to this.
if you are against this, please speak up now.
Pinching in at the last minute, as I'm completely overswamped by work at
this time (writing a template engine, u know, can be hard)...
We've got some _serious_ problems with sessions lately at VNU. The problem
we faced is that in 99.9% of the containers out there sessions, by
containers, are identified uniquely with a cookie stored on the client side.
What does that mean? That no matter how many browser windows you have open,
your client will uniquely be identified by the server as "one".
I am not sure if I am misunderstanding what you are saying here ;)
But I just tested this on a FlowApp I am writing ATM and I can do two different jobs in two different windows of the same client at the same time.
I am using the JXForms framework, so I have s Session by default.
The cookie in each window is the same, but not the continuation id.
One thing that is different about my Flow to all the others I have seen is that it is designed not to have the Model that is being edited as a global variable of the Script.
My model is only retained internally to a function, and you stay in that function (or sub-function) until the job is done.
I am using Hibernate for persistence (maybe this makes it easier).
I open a new Hibernate Session at Function invocation, closing it on exit.
Each function called externally is provided with an identifier to the object that wants editing.
I don't know if this helps ;)
regards Jeremy
