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 cocoon.request.getSession().
Regards,
Chris
