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 <musa...@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 <d...@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-unsubscr...@struts.apache.org
>> For additional commands, e-mail: dev-h...@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> For additional commands, e-mail: dev-h...@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
