struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Siman <aleksandr.si...@gmail.com>
Subject Re: Conversations (continued from "struts 2.2 and guice")
Date Fri, 11 Dec 2009 10:39:44 GMT

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-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message