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.si...@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 <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 >> >> >> > > -- > 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-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
