struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Musachy Barroso <musa...@gmail.com>
Subject Re: Conversations (continued from "struts 2.2 and guice")
Date Tue, 15 Dec 2009 16:10:09 GMT
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 <aleksandr.siman@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 <musachy@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 <dale@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


Mime
View raw message