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