Seems like you are implementing continuations to me. But the point I'm trying to make is that if it is already built-in the web framework, you don't need to do it yourself, and there are actually production ready frameworks with this kind of functionality.
Gabriel 2009/12/11 Alex Siman <aleksandr.si...@gmail.com>: > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
