I have created such wizard: - simple LRU cache based on HashMap with fixed capacity, say for 5 elems; - each cache elem collects wizard data; - this cache stored in user session; - each request in wizard flow pass the ID - the key of element (wizard data) in cache; - when wizard get finished - the elem get removed from cache by ID;
What do you think about this approach? Gabriel Belingueres-2 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 > > > -- View this message in context: http://old.nabble.com/Conversations-%28continued-from-%22struts-2.2-and-guice%22%29-tp26737327p26742058.html Sent from the Struts - Dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
