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 ;-).
Great, integration between different not-all-flowable parts is a *real* need for sessions in the FOM.
So +1 to add it.
Anybody against it?
Stefano.
