You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Gabriel Belingueres <be...@gmail.com> on 2009/12/11 02:22:26 UTC
Conversations (continued from "struts 2.2 and guice")
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
Re: Conversations (continued from "struts 2.2 and guice")
Posted by Roger <ro...@googlemail.com>.
On Saturday 12 December 2009 00:24:41 Dale Newfield wrote:
> Gabriel Belingueres wrote:
> > built-in the web framework
>
> In order to do this we'd need to add in some information in the form and
> in every link leading from one page of the form to another so that it's
> constantly submitted to the server to keep the user associated with the
> right conversation.
>
> The former could be done by adding a hidden element in the s:form
> freemarker templates, and adding an interceptor that notices that value
> and does the right thing (sortof like the checkbox interceptor, but
> instead of modifying the request parameters it has to swap in the target
> object -- I guess this only makes sense when used in combination with
> the modelDriven framework (which I've always avoided)).
>
> The latter is non-trivial (well, the same interceptor would work). It
> would mean context-sensitive changes to the output of the URL tag. It
> wouldn't be too tough for the url tag to look and see if it's inside a
> s:form tag, but what about other links on the page outside the bounds of
> the form? What about ones generated before the form open tag?
>
Dumb question, but why not have a seperate set of "wizard" tags and avoid
having to guess the context? Or maybe even just an additional "wizard='true'
attribute?
Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Conversations (continued from "struts 2.2 and guice")
Posted by Gabriel Belingueres <be...@gmail.com>.
Alex:
Actually I've chosen the "conversations in web applications" subject
for my thesis, and I intended to demonstrate a working conversation
implementation using S2 as the code base (nice candidate framework
since it doesn't support them and I have some much experience with it
from my daily work.)
I took the opportunity to talk about some of my ideas because the
subject came up in the mailing list, and perhaps find some useful
comments for improvements, but please I'm not trying to sell anything
here, and what I finally implement may or may not end up in the S2
code base (so I will probably implement it anyway.)
As such, working on the SWF plugin is not my top priority right now.
BTW, SWF is a fine framework but is not free of bugs either: I was
astonished to find that if you run an app on a Tomcat server which is
installed in a directory with spaces in it, it will not work! (SWF
2.0.8). So if you have Tomcat installed in for ex. "C:\program
files\apache software foundation" not even the demo .war files you
download from the Springsource's web site will work. See
http://www.icefaces.org/JForum/posts/list/6791.page
Gabriel
2009/12/15 Musachy Barroso <mu...@gmail.com>:
> Tom is the owner, he wrote it and gave me access. I was going to fix
> it up for SWF 2, but after my struts project got shot down I never
> touched it. If anyone wants to help with it let me know, I don't have
> any plans to update it myself, but I could help.
>
> musachy
>
> On Tue, Dec 15, 2009 at 9:57 AM, Alex Siman <al...@gmail.com> wrote:
>>
>> I have take a look at SWF plugin (http://code.google.com/p/struts2webflow/)
>> and it seems like that development stopped:
>> http://code.google.com/p/struts2webflow/issues/detail?id=19
>>
>> Musachy, I see you in the "Project owners". Do you have any plans on that
>> plugin?
>>
>> Gabriel, do you have a will to fix that plugin?
>>
>> Musachy Barroso wrote:
>>>
>>> That's what I said. I honestly don't see the point in reinventing the
>>> wheel :)
>>>
>>> On Tue, Dec 15, 2009 at 7:52 AM, Alex Siman <al...@gmail.com>
>>> wrote:
>>>>
>>>> Who would implement all of these features? So many work and potential
>>>> bugs...
>>>>
>>>> Maybe it's the way easier to update SWF plugin to version 2?
>>>>
>>>> Gabriel Belingueres-2 wrote:
>>>>>
>>>>> I also agree that implementing something similar to SWF2 is not very
>>>>> compelling.
>>>>>
>>>>> However having implemented conversations build it in the framework
>>>>> have its advantages, mostly because I'm not sure if it can be
>>>>> implemented/integrated very cleanly/easily writing a third party
>>>>> plugin.
>>>>>
>>>>> I was thinking on which features would need to have an implementation
>>>>> of conversations for S2:
>>>>>
>>>>> * Automatic propagation of the conversationId parameter using S2 tags
>>>>> (s:url, s:form, s:action, s:include) unless some no propagation
>>>>> attribute is specified? (implies modify the simple template)
>>>>>
>>>>> * The s:token tag would put the token in conversation scope (need a
>>>>> new token interceptor?)
>>>>>
>>>>> * Add new objects to access from pages:
>>>>> - add a #conversation inside the context map (just like #session,
>>>>> #application, etc.)
>>>>> - modify #attr object to search the current conversation before
>>>>> session
>>>>>
>>>>> * API:
>>>>> - Add interfaces resembling session scope: ConversationAware that
>>>>> injects a Map<String, Object>.
>>>>> - Add interface to access low level functionality, like getting
>>>>> the conversationId, begin/end conversation, get the conversation map,
>>>>> etc.
>>>>> - Add conversation control with annotations? @Begin, @End?
>>>>> - Add additional control flags to action methods? (I did this in
>>>>> an implementation) Something similar to transaction demarcation:
>>>>> Required, RequiresNew, NotSupported, etc.
>>>>>
>>>>> * Bijection with annotations: Not fundamentally necessary but a neat
>>>>> feature: @In, @Out
>>>>>
>>>>> * Nested conversations support? Similar to Seam (but maybe we can find
>>>>> a way of storing conversation values in a ValueStack, instead of a
>>>>> Map)
>>>>>
>>>>> * Natural conversation ids support: Implies the user supply the
>>>>> conversation id (not hard to implement).
>>>>>
>>>>>
>>>>>
>>>>> I don't know if those features can be obtained by hooking of the
>>>>> plugin extension points.
>>>>>
>>>>> Also all this modifications make me think that perhaps the least
>>>>> intrusive thing to do would be to add a new defaultStack (supporting
>>>>> conversations) instead of modify the current one?
>>>>>
>>>>> Gabriel
>>>>>
>>>>> 2009/12/11 Musachy Barroso <mu...@gmail.com>:
>>>>>> It would be a lot easier to fix the struts plugin to work with SWF 2.
>>>>>> Reinventing the wheel is evil.
>>>>>>
>>>>>> musachy
>>>>>>
>>>>>> On Fri, Dec 11, 2009 at 2:24 PM, Dale Newfield <da...@newfield.org>
>>>>>> wrote:
>>>>>>> Gabriel Belingueres wrote:
>>>>>>>>
>>>>>>>> built-in the web framework
>>>>>>>
>>>>>>> In order to do this we'd need to add in some information in the form
>>>>>>> and
>>>>>>> in
>>>>>>> every link leading from one page of the form to another so that it's
>>>>>>> constantly submitted to the server to keep the user associated with
>>>>>>> the
>>>>>>> right conversation.
>>>>>>>
>>>>>>> The former could be done by adding a hidden element in the s:form
>>>>>>> freemarker
>>>>>>> templates, and adding an interceptor that notices that value and does
>>>>>>> the
>>>>>>> right thing (sortof like the checkbox interceptor, but instead of
>>>>>>> modifying
>>>>>>> the request parameters it has to swap in the target object -- I guess
>>>>>>> this
>>>>>>> only makes sense when used in combination with the modelDriven
>>>>>>> framework
>>>>>>> (which I've always avoided)).
>>>>>>>
>>>>>>> The latter is non-trivial (well, the same interceptor would work). It
>>>>>>> would
>>>>>>> mean context-sensitive changes to the output of the URL tag. It
>>>>>>> wouldn't be
>>>>>>> too tough for the url tag to look and see if it's inside a s:form tag,
>>>>>>> but
>>>>>>> what about other links on the page outside the bounds of the form?
>>>>>>> What
>>>>>>> about ones generated before the form open tag?
>>>>>>>
>>>>>>> I guess what I'm trying to say is that to get something like this
>>>>>>> working
>>>>>>> there are a bunch of moving parts that effect a number of pieces of
>>>>>>> the
>>>>>>> framework, and cause the framework to have to inject much more "magic"
>>>>>>> into
>>>>>>> the rendered pages. If it were built in as part of the framework I'd
>>>>>>> still
>>>>>>> want it to need to be explicitly specified wherever it's desired
>>>>>>> (extra
>>>>>>> attributes on the form, url, and every input tag) so that we don't
>>>>>>> have
>>>>>>> users getting freaked out about all the extra stuff in their pages
>>>>>>> that
>>>>>>> they
>>>>>>> didn't ask for.
>>>>>>>
>>>>>>> -Dale
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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-tp26737327p26795875.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
>>>
>>>
>>>
>>
>> --
>> View this message in context: http://old.nabble.com/Conversations-%28continued-from-%22struts-2.2-and-guice%22%29-tp26737327p26798947.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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Conversations (continued from "struts 2.2 and guice")
Posted by Musachy Barroso <mu...@gmail.com>.
Tom is the owner, he wrote it and gave me access. I was going to fix
it up for SWF 2, but after my struts project got shot down I never
touched it. If anyone wants to help with it let me know, I don't have
any plans to update it myself, but I could help.
musachy
On Tue, Dec 15, 2009 at 9:57 AM, Alex Siman <al...@gmail.com> wrote:
>
> I have take a look at SWF plugin (http://code.google.com/p/struts2webflow/)
> and it seems like that development stopped:
> http://code.google.com/p/struts2webflow/issues/detail?id=19
>
> Musachy, I see you in the "Project owners". Do you have any plans on that
> plugin?
>
> Gabriel, do you have a will to fix that plugin?
>
> Musachy Barroso wrote:
>>
>> That's what I said. I honestly don't see the point in reinventing the
>> wheel :)
>>
>> On Tue, Dec 15, 2009 at 7:52 AM, Alex Siman <al...@gmail.com>
>> wrote:
>>>
>>> Who would implement all of these features? So many work and potential
>>> bugs...
>>>
>>> Maybe it's the way easier to update SWF plugin to version 2?
>>>
>>> Gabriel Belingueres-2 wrote:
>>>>
>>>> I also agree that implementing something similar to SWF2 is not very
>>>> compelling.
>>>>
>>>> However having implemented conversations build it in the framework
>>>> have its advantages, mostly because I'm not sure if it can be
>>>> implemented/integrated very cleanly/easily writing a third party
>>>> plugin.
>>>>
>>>> I was thinking on which features would need to have an implementation
>>>> of conversations for S2:
>>>>
>>>> * Automatic propagation of the conversationId parameter using S2 tags
>>>> (s:url, s:form, s:action, s:include) unless some no propagation
>>>> attribute is specified? (implies modify the simple template)
>>>>
>>>> * The s:token tag would put the token in conversation scope (need a
>>>> new token interceptor?)
>>>>
>>>> * Add new objects to access from pages:
>>>> - add a #conversation inside the context map (just like #session,
>>>> #application, etc.)
>>>> - modify #attr object to search the current conversation before
>>>> session
>>>>
>>>> * API:
>>>> - Add interfaces resembling session scope: ConversationAware that
>>>> injects a Map<String, Object>.
>>>> - Add interface to access low level functionality, like getting
>>>> the conversationId, begin/end conversation, get the conversation map,
>>>> etc.
>>>> - Add conversation control with annotations? @Begin, @End?
>>>> - Add additional control flags to action methods? (I did this in
>>>> an implementation) Something similar to transaction demarcation:
>>>> Required, RequiresNew, NotSupported, etc.
>>>>
>>>> * Bijection with annotations: Not fundamentally necessary but a neat
>>>> feature: @In, @Out
>>>>
>>>> * Nested conversations support? Similar to Seam (but maybe we can find
>>>> a way of storing conversation values in a ValueStack, instead of a
>>>> Map)
>>>>
>>>> * Natural conversation ids support: Implies the user supply the
>>>> conversation id (not hard to implement).
>>>>
>>>>
>>>>
>>>> I don't know if those features can be obtained by hooking of the
>>>> plugin extension points.
>>>>
>>>> Also all this modifications make me think that perhaps the least
>>>> intrusive thing to do would be to add a new defaultStack (supporting
>>>> conversations) instead of modify the current one?
>>>>
>>>> Gabriel
>>>>
>>>> 2009/12/11 Musachy Barroso <mu...@gmail.com>:
>>>>> It would be a lot easier to fix the struts plugin to work with SWF 2.
>>>>> Reinventing the wheel is evil.
>>>>>
>>>>> musachy
>>>>>
>>>>> On Fri, Dec 11, 2009 at 2:24 PM, Dale Newfield <da...@newfield.org>
>>>>> wrote:
>>>>>> Gabriel Belingueres wrote:
>>>>>>>
>>>>>>> built-in the web framework
>>>>>>
>>>>>> In order to do this we'd need to add in some information in the form
>>>>>> and
>>>>>> in
>>>>>> every link leading from one page of the form to another so that it's
>>>>>> constantly submitted to the server to keep the user associated with
>>>>>> the
>>>>>> right conversation.
>>>>>>
>>>>>> The former could be done by adding a hidden element in the s:form
>>>>>> freemarker
>>>>>> templates, and adding an interceptor that notices that value and does
>>>>>> the
>>>>>> right thing (sortof like the checkbox interceptor, but instead of
>>>>>> modifying
>>>>>> the request parameters it has to swap in the target object -- I guess
>>>>>> this
>>>>>> only makes sense when used in combination with the modelDriven
>>>>>> framework
>>>>>> (which I've always avoided)).
>>>>>>
>>>>>> The latter is non-trivial (well, the same interceptor would work). It
>>>>>> would
>>>>>> mean context-sensitive changes to the output of the URL tag. It
>>>>>> wouldn't be
>>>>>> too tough for the url tag to look and see if it's inside a s:form tag,
>>>>>> but
>>>>>> what about other links on the page outside the bounds of the form?
>>>>>> What
>>>>>> about ones generated before the form open tag?
>>>>>>
>>>>>> I guess what I'm trying to say is that to get something like this
>>>>>> working
>>>>>> there are a bunch of moving parts that effect a number of pieces of
>>>>>> the
>>>>>> framework, and cause the framework to have to inject much more "magic"
>>>>>> into
>>>>>> the rendered pages. If it were built in as part of the framework I'd
>>>>>> still
>>>>>> want it to need to be explicitly specified wherever it's desired
>>>>>> (extra
>>>>>> attributes on the form, url, and every input tag) so that we don't
>>>>>> have
>>>>>> users getting freaked out about all the extra stuff in their pages
>>>>>> that
>>>>>> they
>>>>>> didn't ask for.
>>>>>>
>>>>>> -Dale
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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-tp26737327p26795875.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
>>
>>
>>
>
> --
> View this message in context: http://old.nabble.com/Conversations-%28continued-from-%22struts-2.2-and-guice%22%29-tp26737327p26798947.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
Re: Conversations (continued from "struts 2.2 and guice")
Posted by Alex Siman <al...@gmail.com>.
I have take a look at SWF plugin (http://code.google.com/p/struts2webflow/)
and it seems like that development stopped:
http://code.google.com/p/struts2webflow/issues/detail?id=19
Musachy, I see you in the "Project owners". Do you have any plans on that
plugin?
Gabriel, do you have a will to fix that plugin?
Musachy Barroso wrote:
>
> That's what I said. I honestly don't see the point in reinventing the
> wheel :)
>
> On Tue, Dec 15, 2009 at 7:52 AM, Alex Siman <al...@gmail.com>
> wrote:
>>
>> Who would implement all of these features? So many work and potential
>> bugs...
>>
>> Maybe it's the way easier to update SWF plugin to version 2?
>>
>> Gabriel Belingueres-2 wrote:
>>>
>>> I also agree that implementing something similar to SWF2 is not very
>>> compelling.
>>>
>>> However having implemented conversations build it in the framework
>>> have its advantages, mostly because I'm not sure if it can be
>>> implemented/integrated very cleanly/easily writing a third party
>>> plugin.
>>>
>>> I was thinking on which features would need to have an implementation
>>> of conversations for S2:
>>>
>>> * Automatic propagation of the conversationId parameter using S2 tags
>>> (s:url, s:form, s:action, s:include) unless some no propagation
>>> attribute is specified? (implies modify the simple template)
>>>
>>> * The s:token tag would put the token in conversation scope (need a
>>> new token interceptor?)
>>>
>>> * Add new objects to access from pages:
>>> - add a #conversation inside the context map (just like #session,
>>> #application, etc.)
>>> - modify #attr object to search the current conversation before
>>> session
>>>
>>> * API:
>>> - Add interfaces resembling session scope: ConversationAware that
>>> injects a Map<String, Object>.
>>> - Add interface to access low level functionality, like getting
>>> the conversationId, begin/end conversation, get the conversation map,
>>> etc.
>>> - Add conversation control with annotations? @Begin, @End?
>>> - Add additional control flags to action methods? (I did this in
>>> an implementation) Something similar to transaction demarcation:
>>> Required, RequiresNew, NotSupported, etc.
>>>
>>> * Bijection with annotations: Not fundamentally necessary but a neat
>>> feature: @In, @Out
>>>
>>> * Nested conversations support? Similar to Seam (but maybe we can find
>>> a way of storing conversation values in a ValueStack, instead of a
>>> Map)
>>>
>>> * Natural conversation ids support: Implies the user supply the
>>> conversation id (not hard to implement).
>>>
>>>
>>>
>>> I don't know if those features can be obtained by hooking of the
>>> plugin extension points.
>>>
>>> Also all this modifications make me think that perhaps the least
>>> intrusive thing to do would be to add a new defaultStack (supporting
>>> conversations) instead of modify the current one?
>>>
>>> Gabriel
>>>
>>> 2009/12/11 Musachy Barroso <mu...@gmail.com>:
>>>> It would be a lot easier to fix the struts plugin to work with SWF 2.
>>>> Reinventing the wheel is evil.
>>>>
>>>> musachy
>>>>
>>>> On Fri, Dec 11, 2009 at 2:24 PM, Dale Newfield <da...@newfield.org>
>>>> wrote:
>>>>> Gabriel Belingueres wrote:
>>>>>>
>>>>>> built-in the web framework
>>>>>
>>>>> In order to do this we'd need to add in some information in the form
>>>>> and
>>>>> in
>>>>> every link leading from one page of the form to another so that it's
>>>>> constantly submitted to the server to keep the user associated with
>>>>> the
>>>>> right conversation.
>>>>>
>>>>> The former could be done by adding a hidden element in the s:form
>>>>> freemarker
>>>>> templates, and adding an interceptor that notices that value and does
>>>>> the
>>>>> right thing (sortof like the checkbox interceptor, but instead of
>>>>> modifying
>>>>> the request parameters it has to swap in the target object -- I guess
>>>>> this
>>>>> only makes sense when used in combination with the modelDriven
>>>>> framework
>>>>> (which I've always avoided)).
>>>>>
>>>>> The latter is non-trivial (well, the same interceptor would work). It
>>>>> would
>>>>> mean context-sensitive changes to the output of the URL tag. It
>>>>> wouldn't be
>>>>> too tough for the url tag to look and see if it's inside a s:form tag,
>>>>> but
>>>>> what about other links on the page outside the bounds of the form?
>>>>> What
>>>>> about ones generated before the form open tag?
>>>>>
>>>>> I guess what I'm trying to say is that to get something like this
>>>>> working
>>>>> there are a bunch of moving parts that effect a number of pieces of
>>>>> the
>>>>> framework, and cause the framework to have to inject much more "magic"
>>>>> into
>>>>> the rendered pages. If it were built in as part of the framework I'd
>>>>> still
>>>>> want it to need to be explicitly specified wherever it's desired
>>>>> (extra
>>>>> attributes on the form, url, and every input tag) so that we don't
>>>>> have
>>>>> users getting freaked out about all the extra stuff in their pages
>>>>> that
>>>>> they
>>>>> didn't ask for.
>>>>>
>>>>> -Dale
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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-tp26737327p26795875.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
>
>
>
--
View this message in context: http://old.nabble.com/Conversations-%28continued-from-%22struts-2.2-and-guice%22%29-tp26737327p26798947.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
Re: Conversations (continued from "struts 2.2 and guice")
Posted by Musachy Barroso <mu...@gmail.com>.
That's what I said. I honestly don't see the point in reinventing the wheel :)
On Tue, Dec 15, 2009 at 7:52 AM, Alex Siman <al...@gmail.com> wrote:
>
> Who would implement all of these features? So many work and potential bugs...
>
> Maybe it's the way easier to update SWF plugin to version 2?
>
> Gabriel Belingueres-2 wrote:
>>
>> I also agree that implementing something similar to SWF2 is not very
>> compelling.
>>
>> However having implemented conversations build it in the framework
>> have its advantages, mostly because I'm not sure if it can be
>> implemented/integrated very cleanly/easily writing a third party
>> plugin.
>>
>> I was thinking on which features would need to have an implementation
>> of conversations for S2:
>>
>> * Automatic propagation of the conversationId parameter using S2 tags
>> (s:url, s:form, s:action, s:include) unless some no propagation
>> attribute is specified? (implies modify the simple template)
>>
>> * The s:token tag would put the token in conversation scope (need a
>> new token interceptor?)
>>
>> * Add new objects to access from pages:
>> - add a #conversation inside the context map (just like #session,
>> #application, etc.)
>> - modify #attr object to search the current conversation before
>> session
>>
>> * API:
>> - Add interfaces resembling session scope: ConversationAware that
>> injects a Map<String, Object>.
>> - Add interface to access low level functionality, like getting
>> the conversationId, begin/end conversation, get the conversation map,
>> etc.
>> - Add conversation control with annotations? @Begin, @End?
>> - Add additional control flags to action methods? (I did this in
>> an implementation) Something similar to transaction demarcation:
>> Required, RequiresNew, NotSupported, etc.
>>
>> * Bijection with annotations: Not fundamentally necessary but a neat
>> feature: @In, @Out
>>
>> * Nested conversations support? Similar to Seam (but maybe we can find
>> a way of storing conversation values in a ValueStack, instead of a
>> Map)
>>
>> * Natural conversation ids support: Implies the user supply the
>> conversation id (not hard to implement).
>>
>>
>>
>> I don't know if those features can be obtained by hooking of the
>> plugin extension points.
>>
>> Also all this modifications make me think that perhaps the least
>> intrusive thing to do would be to add a new defaultStack (supporting
>> conversations) instead of modify the current one?
>>
>> Gabriel
>>
>> 2009/12/11 Musachy Barroso <mu...@gmail.com>:
>>> It would be a lot easier to fix the struts plugin to work with SWF 2.
>>> Reinventing the wheel is evil.
>>>
>>> musachy
>>>
>>> On Fri, Dec 11, 2009 at 2:24 PM, Dale Newfield <da...@newfield.org> wrote:
>>>> Gabriel Belingueres wrote:
>>>>>
>>>>> built-in the web framework
>>>>
>>>> In order to do this we'd need to add in some information in the form and
>>>> in
>>>> every link leading from one page of the form to another so that it's
>>>> constantly submitted to the server to keep the user associated with the
>>>> right conversation.
>>>>
>>>> The former could be done by adding a hidden element in the s:form
>>>> freemarker
>>>> templates, and adding an interceptor that notices that value and does
>>>> the
>>>> right thing (sortof like the checkbox interceptor, but instead of
>>>> modifying
>>>> the request parameters it has to swap in the target object -- I guess
>>>> this
>>>> only makes sense when used in combination with the modelDriven framework
>>>> (which I've always avoided)).
>>>>
>>>> The latter is non-trivial (well, the same interceptor would work). It
>>>> would
>>>> mean context-sensitive changes to the output of the URL tag. It
>>>> wouldn't be
>>>> too tough for the url tag to look and see if it's inside a s:form tag,
>>>> but
>>>> what about other links on the page outside the bounds of the form? What
>>>> about ones generated before the form open tag?
>>>>
>>>> I guess what I'm trying to say is that to get something like this
>>>> working
>>>> there are a bunch of moving parts that effect a number of pieces of the
>>>> framework, and cause the framework to have to inject much more "magic"
>>>> into
>>>> the rendered pages. If it were built in as part of the framework I'd
>>>> still
>>>> want it to need to be explicitly specified wherever it's desired (extra
>>>> attributes on the form, url, and every input tag) so that we don't have
>>>> users getting freaked out about all the extra stuff in their pages that
>>>> they
>>>> didn't ask for.
>>>>
>>>> -Dale
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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-tp26737327p26795875.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
Re: Conversations (continued from "struts 2.2 and guice")
Posted by Alex Siman <al...@gmail.com>.
Who would implement all of these features? So many work and potential bugs...
Maybe it's the way easier to update SWF plugin to version 2?
Gabriel Belingueres-2 wrote:
>
> I also agree that implementing something similar to SWF2 is not very
> compelling.
>
> However having implemented conversations build it in the framework
> have its advantages, mostly because I'm not sure if it can be
> implemented/integrated very cleanly/easily writing a third party
> plugin.
>
> I was thinking on which features would need to have an implementation
> of conversations for S2:
>
> * Automatic propagation of the conversationId parameter using S2 tags
> (s:url, s:form, s:action, s:include) unless some no propagation
> attribute is specified? (implies modify the simple template)
>
> * The s:token tag would put the token in conversation scope (need a
> new token interceptor?)
>
> * Add new objects to access from pages:
> - add a #conversation inside the context map (just like #session,
> #application, etc.)
> - modify #attr object to search the current conversation before
> session
>
> * API:
> - Add interfaces resembling session scope: ConversationAware that
> injects a Map<String, Object>.
> - Add interface to access low level functionality, like getting
> the conversationId, begin/end conversation, get the conversation map,
> etc.
> - Add conversation control with annotations? @Begin, @End?
> - Add additional control flags to action methods? (I did this in
> an implementation) Something similar to transaction demarcation:
> Required, RequiresNew, NotSupported, etc.
>
> * Bijection with annotations: Not fundamentally necessary but a neat
> feature: @In, @Out
>
> * Nested conversations support? Similar to Seam (but maybe we can find
> a way of storing conversation values in a ValueStack, instead of a
> Map)
>
> * Natural conversation ids support: Implies the user supply the
> conversation id (not hard to implement).
>
>
>
> I don't know if those features can be obtained by hooking of the
> plugin extension points.
>
> Also all this modifications make me think that perhaps the least
> intrusive thing to do would be to add a new defaultStack (supporting
> conversations) instead of modify the current one?
>
> Gabriel
>
> 2009/12/11 Musachy Barroso <mu...@gmail.com>:
>> It would be a lot easier to fix the struts plugin to work with SWF 2.
>> Reinventing the wheel is evil.
>>
>> musachy
>>
>> On Fri, Dec 11, 2009 at 2:24 PM, Dale Newfield <da...@newfield.org> wrote:
>>> Gabriel Belingueres wrote:
>>>>
>>>> built-in the web framework
>>>
>>> In order to do this we'd need to add in some information in the form and
>>> in
>>> every link leading from one page of the form to another so that it's
>>> constantly submitted to the server to keep the user associated with the
>>> right conversation.
>>>
>>> The former could be done by adding a hidden element in the s:form
>>> freemarker
>>> templates, and adding an interceptor that notices that value and does
>>> the
>>> right thing (sortof like the checkbox interceptor, but instead of
>>> modifying
>>> the request parameters it has to swap in the target object -- I guess
>>> this
>>> only makes sense when used in combination with the modelDriven framework
>>> (which I've always avoided)).
>>>
>>> The latter is non-trivial (well, the same interceptor would work). It
>>> would
>>> mean context-sensitive changes to the output of the URL tag. It
>>> wouldn't be
>>> too tough for the url tag to look and see if it's inside a s:form tag,
>>> but
>>> what about other links on the page outside the bounds of the form? What
>>> about ones generated before the form open tag?
>>>
>>> I guess what I'm trying to say is that to get something like this
>>> working
>>> there are a bunch of moving parts that effect a number of pieces of the
>>> framework, and cause the framework to have to inject much more "magic"
>>> into
>>> the rendered pages. If it were built in as part of the framework I'd
>>> still
>>> want it to need to be explicitly specified wherever it's desired (extra
>>> attributes on the form, url, and every input tag) so that we don't have
>>> users getting freaked out about all the extra stuff in their pages that
>>> they
>>> didn't ask for.
>>>
>>> -Dale
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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-tp26737327p26795875.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
Re: Conversations (continued from "struts 2.2 and guice")
Posted by Gabriel Belingueres <be...@gmail.com>.
I also agree that implementing something similar to SWF2 is not very compelling.
However having implemented conversations build it in the framework
have its advantages, mostly because I'm not sure if it can be
implemented/integrated very cleanly/easily writing a third party
plugin.
I was thinking on which features would need to have an implementation
of conversations for S2:
* Automatic propagation of the conversationId parameter using S2 tags
(s:url, s:form, s:action, s:include) unless some no propagation
attribute is specified? (implies modify the simple template)
* The s:token tag would put the token in conversation scope (need a
new token interceptor?)
* Add new objects to access from pages:
- add a #conversation inside the context map (just like #session,
#application, etc.)
- modify #attr object to search the current conversation before session
* API:
- Add interfaces resembling session scope: ConversationAware that
injects a Map<String, Object>.
- Add interface to access low level functionality, like getting
the conversationId, begin/end conversation, get the conversation map,
etc.
- Add conversation control with annotations? @Begin, @End?
- Add additional control flags to action methods? (I did this in
an implementation) Something similar to transaction demarcation:
Required, RequiresNew, NotSupported, etc.
* Bijection with annotations: Not fundamentally necessary but a neat
feature: @In, @Out
* Nested conversations support? Similar to Seam (but maybe we can find
a way of storing conversation values in a ValueStack, instead of a
Map)
* Natural conversation ids support: Implies the user supply the
conversation id (not hard to implement).
I don't know if those features can be obtained by hooking of the
plugin extension points.
Also all this modifications make me think that perhaps the least
intrusive thing to do would be to add a new defaultStack (supporting
conversations) instead of modify the current one?
Gabriel
2009/12/11 Musachy Barroso <mu...@gmail.com>:
> It would be a lot easier to fix the struts plugin to work with SWF 2.
> Reinventing the wheel is evil.
>
> musachy
>
> On Fri, Dec 11, 2009 at 2:24 PM, Dale Newfield <da...@newfield.org> wrote:
>> Gabriel Belingueres wrote:
>>>
>>> built-in the web framework
>>
>> In order to do this we'd need to add in some information in the form and in
>> every link leading from one page of the form to another so that it's
>> constantly submitted to the server to keep the user associated with the
>> right conversation.
>>
>> The former could be done by adding a hidden element in the s:form freemarker
>> templates, and adding an interceptor that notices that value and does the
>> right thing (sortof like the checkbox interceptor, but instead of modifying
>> the request parameters it has to swap in the target object -- I guess this
>> only makes sense when used in combination with the modelDriven framework
>> (which I've always avoided)).
>>
>> The latter is non-trivial (well, the same interceptor would work). It would
>> mean context-sensitive changes to the output of the URL tag. It wouldn't be
>> too tough for the url tag to look and see if it's inside a s:form tag, but
>> what about other links on the page outside the bounds of the form? What
>> about ones generated before the form open tag?
>>
>> I guess what I'm trying to say is that to get something like this working
>> there are a bunch of moving parts that effect a number of pieces of the
>> framework, and cause the framework to have to inject much more "magic" into
>> the rendered pages. If it were built in as part of the framework I'd still
>> want it to need to be explicitly specified wherever it's desired (extra
>> attributes on the form, url, and every input tag) so that we don't have
>> users getting freaked out about all the extra stuff in their pages that they
>> didn't ask for.
>>
>> -Dale
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Conversations (continued from "struts 2.2 and guice")
Posted by Musachy Barroso <mu...@gmail.com>.
It would be a lot easier to fix the struts plugin to work with SWF 2.
Reinventing the wheel is evil.
musachy
On Fri, Dec 11, 2009 at 2:24 PM, Dale Newfield <da...@newfield.org> wrote:
> Gabriel Belingueres wrote:
>>
>> built-in the web framework
>
> In order to do this we'd need to add in some information in the form and in
> every link leading from one page of the form to another so that it's
> constantly submitted to the server to keep the user associated with the
> right conversation.
>
> The former could be done by adding a hidden element in the s:form freemarker
> templates, and adding an interceptor that notices that value and does the
> right thing (sortof like the checkbox interceptor, but instead of modifying
> the request parameters it has to swap in the target object -- I guess this
> only makes sense when used in combination with the modelDriven framework
> (which I've always avoided)).
>
> The latter is non-trivial (well, the same interceptor would work). It would
> mean context-sensitive changes to the output of the URL tag. It wouldn't be
> too tough for the url tag to look and see if it's inside a s:form tag, but
> what about other links on the page outside the bounds of the form? What
> about ones generated before the form open tag?
>
> I guess what I'm trying to say is that to get something like this working
> there are a bunch of moving parts that effect a number of pieces of the
> framework, and cause the framework to have to inject much more "magic" into
> the rendered pages. If it were built in as part of the framework I'd still
> want it to need to be explicitly specified wherever it's desired (extra
> attributes on the form, url, and every input tag) so that we don't have
> users getting freaked out about all the extra stuff in their pages that they
> didn't ask for.
>
> -Dale
>
> ---------------------------------------------------------------------
> 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
Re: Conversations (continued from "struts 2.2 and guice")
Posted by Dale Newfield <da...@newfield.org>.
Gabriel Belingueres wrote:
> built-in the web framework
In order to do this we'd need to add in some information in the form and
in every link leading from one page of the form to another so that it's
constantly submitted to the server to keep the user associated with the
right conversation.
The former could be done by adding a hidden element in the s:form
freemarker templates, and adding an interceptor that notices that value
and does the right thing (sortof like the checkbox interceptor, but
instead of modifying the request parameters it has to swap in the target
object -- I guess this only makes sense when used in combination with
the modelDriven framework (which I've always avoided)).
The latter is non-trivial (well, the same interceptor would work). It
would mean context-sensitive changes to the output of the URL tag. It
wouldn't be too tough for the url tag to look and see if it's inside a
s:form tag, but what about other links on the page outside the bounds of
the form? What about ones generated before the form open tag?
I guess what I'm trying to say is that to get something like this
working there are a bunch of moving parts that effect a number of pieces
of the framework, and cause the framework to have to inject much more
"magic" into the rendered pages. If it were built in as part of the
framework I'd still want it to need to be explicitly specified wherever
it's desired (extra attributes on the form, url, and every input tag) so
that we don't have users getting freaked out about all the extra stuff
in their pages that they didn't ask for.
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Conversations (continued from "struts 2.2 and guice")
Posted by Gabriel Belingueres <be...@gmail.com>.
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 <al...@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-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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Conversations (continued from "struts 2.2 and guice")
Posted by Alex Siman <al...@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-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
Re: Conversations (continued from "struts 2.2 and guice")
Posted by Brian Pontarelli <br...@pontarelli.com>.
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-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