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