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 18:01:08 GMT
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 <aleksandr.siman@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 <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
>>
>>
>>
>
> --
> 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


Mime
View raw message