|
From: Erwin V. <erw...@er...> - 2005-04-02 17:27:52
|
> What about an implementation that would 'do what is best'. Save to > the session if it already exists, serialize to the request if not. > Then have a custom tag to spit out the flow info in the form. The tag > would pull the serialized flow info from the request (if it exists) > and add a new hidden input field for it (_flowInstance or > something)...otherwise if a session exists and the info is on the > session it would spit out what is expected now (the _* hidden fields). > At the beginning of a request, it would look to see if the serialized > param (_flowInstance) is on the request first...if so, deserialize. > If not, see if a session exists and pull from the session using _* > params. Interesting idea to have it automatically select request or session based storage. I added pluggable FlowExecutionStorage strategies this morning so this would be trivial to do. Also, I implemented a "client side flow execution" storage strategy and it is just encoding the entire flow execution in the flowExecutionId. No need for any special handling in the views, the storage strategy is completely pluggable! > If you have a truly complex object graph, set a 'requiresSession' > boolean to true (defaults to false)...although I would think it best > to try and keep it as simple as possible when going in the session. > > With this approach your not doing more than you need (when a session > does exist), and (as a bonus) you can have flows that are used by > non-session visitors and with-session users, and the impl would 'do > what is best' in both situations. Yep, nice! I'm sure Keith is gonna blog about it, but <gavingKingMode> our new pluggable flow execution storage strategies kick some serious butt! </gavingKingMode> :) |