This is how most frameworks do it, with continuations. This is essentially trying to do client side storage on the server. The reason it stores information like that is because of the Back/Forward buttons and multiple windows. All of which are client side interactions without a server-side notification (one of the pains of HTTP).
You can handle most wizards using client side storage as well and reduce the complexity of server-side state management. This also allows more transparent scaling as the server could be stateless (sometimes). The tricky part is security becomes an issue unless you encrypt all the data and the store it using Base64 or something. With HTML5 and the client side databases (yeah I know they are a ways off) I would expect to see less requirements for continuations and web-flows. -bp On Dec 10, 2009, at 6:22 PM, Gabriel Belingueres wrote: > I think this case is correctly handled in SWF: Each time a request > fires a state transition, SWF saves a "continuation" of the current > data (think the Memento pattern) Serialized for later use. > When the user right-click the "next" link opening a new window, the > state transition put the flow in a new state and as such a new > continuation is saved (keeping the last one too.) > From now on, the 2 windows execute on different data sets and no > interference is possible. > SWF only delete all continuations when the flow reaches an end state: > if a new request is received on that deleted flow an exception is > raised (then protecting from multiple submits, back buttons or as in > this case, submits from different windows.) > > This works because it saves multiple (potentially costly?) copies of > the data. As you say, I think JBoss Seam which does support > conversations but has no support for continuations can not detect this > case. > > Gabriel > > ------------------------------------------------------------------------------------ > > That seems like a very imperfect fix for an almost impossible problem. > Having an extra parameter on the link won't stop a user from right clicking > on the link and saying "open in another window" and having 2 "conversations" > with the same conversation key. To my knowledge there's just no way to > accomplish it cleanly and completely, so you might as well embrace the way > the web works and go with it rather than trying to swim upstream. But > that's just one man's opinion. > (*Chris*) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
