|
From: Alef A. <al...@jt...> - 2005-04-01 06:04:46
|
I'm not sure, but when I used this approach I simply serialized = everything I needed, encoded it to a String Base64 String and put it in = a hidden input field. Of course not the most efficient way to do it, but = you don't have to worry about keeping your serialization 'protocol' = up-to-date. It will be a bit much maybe if you have many subflows as = you're saying? regards, Alef -----Original Message----- From: spr...@li... on behalf of = Keith Donald Sent: Fri 4/1/2005 1:00 AM To: spr...@li... Subject: RE: [Springframework-developer] SWF - Creating HTTP sessions - = Feedback needed =20 Just thinking out loud here, but no, I don't think this would be too difficult to implement. There is potentially lot to serialize out on = each request, though, particularly if you a flow execution that has spawned = many nested subflows. Methinks we could have custom tag that serializes the FlowExecutionStack = on each request. This would include serializing: - The ID of the flow execution (randomly generated guid) - The stack of IDs of all spawned flows, the top being the active flow = and the rest any suspended parent flows (if the active flow is a subflow) - For each flow in the stack, everything in 'flow scope'. This does introduce the issue of having to convert from string representations of objects in flow scope on each request, possibly = applying automatic type conversion from attribute metadata (e.g from string -> number). Do you know how this issue is handled in ASP.NET and JSF? Currently FlowExecution storage responsibility is externalized from the = core web.flow system -- the FlowExecutionStack, the central object for = starting and manipulating a single client instance of a top-level flow, is a = safely serializable memento. The HttpServletFlowExecutionManager, by default, = uses HTTP session storage, but the get(..), save(..) and remove(...) methods = that accomplish this could be overridden to serialize to some other place = like a database. A custom HttpServletFlowExecutionManager subclass would likely need to = be written to accomplish deserializing flow state in a hidden form back to = a fully constructed FlowExecutionStack on each request. One issue is = whether it makes sense to refactor this class given that need, and if so how. Keith =20 -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf = Of Alef Arendsen Sent: Thursday, March 31, 2005 4:44 PM To: spr...@li... Subject: Re: [Springframework-developer] SWF - Creating HTTP sessions - Feedback needed It's what ASP.NET (and I think some JSF implementations) does as well -=20 serialization of the state in a hidden input field. I don't think it'd=20 be that difficult to implement a custom tag that does this, wouldn't=20 it? rgds, Alef On Mar 31, 2005, at 10:30 PM, Rob Harrop wrote: > I see no problem in implictly creating a session - although I am=20 > concerned about the impact of this on clustered applications. Can the=20 > session implementation be factored out so that users can implement=20 > their own session storage? > > Rob > > Erwin Vervaet wrote: > >> The Spring Web Flow (SWF) FlowController forces the "requireSession"=20 >> property it inherits from AbstractController to "true". This is=20 >> logical since the webflow system needs to store flow execution state=20 >> in the HTTP session. >> >> So far so good. However, since the controller now requires an=20 >> existing session, the user/developer is responsible for creating that = >> session before a flow is started. This is typically not a problem in=20 >> real-life applications since those carefully manage session creation=20 >> and invalidation. >> >> Still, we are wondering whether it is a good idea to implicitly=20 >> create sessions (usually using request.getSession()) in a controller, = >> or should this be left as a responsability of the application=20 >> developer? Note that AbstractWizardFormController and=20 >> AbstractFormController implicitly create sessions. >> >> Erwin Vervaet >> erw...@er... >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by Demarc: >> A global provider of Threat Management Solutions. >> Download our HomeAdmin security software for free today! >> http://www.demarc.com/info/Sentarus/hamr30 >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> = https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> > > > ------------------------------------------------------- > This SF.net email is sponsored by Demarc: > A global provider of Threat Management Solutions. > Download our HomeAdmin security software for free today! > http://www.demarc.com/info/Sentarus/hamr30 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |