Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (nike.apache.org: domain of belingueres@gmail.com
 designates 209.85.219.227 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=M8Gh73pHgld1byOYrJ4+JAyXAc4Y7sQe2dW+Cf9IwfRKlsSRtsdavcSlfOe6CccnND
         LovI+/s3wG/5K0xyMwBS47VWHBpDWFyN6QqaJDETILY6lKxGLfHk7pTPM1mE9/dl5ylE
         A9zjxBOcX6YiWRWumfhxRg8KA94xXTUhfNbz4=
MIME-Version: 1.0
In-Reply-To: <26742058.post@talk.nabble.com>
References: <cf66e280912101722l4e726364kbe08417089790a6d@mail.gmail.com>
	 <26742058.post@talk.nabble.com>
Date: Fri, 11 Dec 2009 16:50:43 -0300
Message-ID: <cf66e280912111150p6c1e8b94s7217097cc5511dcf@mail.gmail.com>
Subject: Re: Conversations (continued from "struts 2.2 and guice")
From: Gabriel Belingueres <belingueres@gmail.com>
To: Struts Developers List <dev@struts.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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.siman@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 da=
ta)
> 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. =A0To my knowledge there's just no way t=
o
>> accomplish it cleanly and completely, so you might as well embrace the w=
ay
>> the web works and go with it rather than trying to swim upstream. =A0But
>> that's just one man's opinion.
>> =A0(*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-%28cont=
inued-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
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org