struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Siman <>
Subject Re: Conversations (continued from "struts 2.2 and guice")
Date Tue, 15 Dec 2009 15:52:50 GMT

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 <>:
>> 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 <> 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:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View this message in context:
Sent from the Struts - Dev mailing list archive at

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message