cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <>
Subject Re: Discussion of Flow Issues
Date Tue, 18 Mar 2003 18:31:03 GMT
Ugo Cei wrote:
> Sylvain Wallez wrote:
>> Stefano Mazzocchi wrote:
>>>  1) do we really need the session object? the flow is in fact 
>>> deprecating the use of sessions for storing stateful data. I would 
>>> love to *force* people to think into this way by not making the 
>>> session available to them. We can always add it later if users really 
>>> push us for it. 
>> +1. Moreover, the inadequate use of sessions to store data my 
>> completely break what the flow is giving us through continuations.
> I'm using the flow and I'm using sessions too. The applications I'm 
> currently developing with the flow are composed of many independent 
> "flows", each with its own entry point. Consider the case of an 
> e-commerce site. These entry points might be:
> - search for an item
> - add item to cart
> - show cart
> - delete item from cart
> - proceed to checkout
> I don't think I can combine all of these (and many more) in as single 
> flow, held toghether with continuations. But I still have the need to 
> have a user session spanning those operations, and I do this with 
> per-session global variables in the flow. As you might know, global 
> variables in a flowscript are associated with a session when you call 
> cocoon.createSession(). In the above example, the cart, or the user's 
> profile, would be associated with the session.
> I am somehow aware that I am abusing sessions here, and that there is a 
> better way, but it's not that easy to follow, probably. If you can show 
> it to me, I'd be glad to abandon sessions, but if you take them away 
> right now, I'm going to be in trouble ;-).

You're not abusing sessions. cocoon.createSession() exists exactly for 
the purpose you mention. Nobody is suggesting that we remove it. What at 
least I was suggesting, is that because of this (that you can store 
"session" state in global JS variables) direct access to the underlying 
Session should not be needed by the average user of the flow.

Right now you have direct access via cocoon.session and 



View raw message