Alex: Actually I've chosen the "conversations in web applications" subject for my thesis, and I intended to demonstrate a working conversation implementation using S2 as the code base (nice candidate framework since it doesn't support them and I have some much experience with it from my daily work.)
I took the opportunity to talk about some of my ideas because the subject came up in the mailing list, and perhaps find some useful comments for improvements, but please I'm not trying to sell anything here, and what I finally implement may or may not end up in the S2 code base (so I will probably implement it anyway.) As such, working on the SWF plugin is not my top priority right now. BTW, SWF is a fine framework but is not free of bugs either: I was astonished to find that if you run an app on a Tomcat server which is installed in a directory with spaces in it, it will not work! (SWF 2.0.8). So if you have Tomcat installed in for ex. "C:\program files\apache software foundation" not even the demo .war files you download from the Springsource's web site will work. See http://www.icefaces.org/JForum/posts/list/6791.page Gabriel 2009/12/15 Musachy Barroso <musa...@gmail.com>: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
