Re: [Springframework-developer] SWF - Creating HTTP sessions - Feedback needed

[Rob H. <ro...@ca...>]

Exactly what we are doing :)

Alef Arendsen wrote:

> 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
>
> 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
>
> -----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 -
> serialization of the state in a hidden input field. I don't think it'd
> be that difficult to implement a custom tag that does this, wouldn't
> 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
> > concerned about the impact of this on clustered applications. Can the
> > session implementation be factored out so that users can implement
> > their own session storage?
> >
> > Rob
> >
> > Erwin Vervaet wrote:
> >
> >> The Spring Web Flow (SWF) FlowController forces the "requireSession"
> >> property it inherits from AbstractController to "true". This is
> >> logical since the webflow system needs to store flow execution state
> >> in the HTTP session.
> >>
> >> So far so good. However, since the controller now requires an
> >> existing session, the user/developer is responsible for creating that
> >> session before a flow is started. This is typically not a problem in
> >> real-life applications since those carefully manage session creation
> >> and invalidation.
> >>
> >> Still, we are wondering whether it is a good idea to implicitly
> >> create sessions (usually using request.getSession()) in a controller,
> >> or should this be left as a responsability of the application
> >> developer? Note that AbstractWizardFormController and
> >> 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
>
>
>