I have created a google code struts2-jquery-plugin project [ http://code.google.com/p/struts2-jquery-plugin/] and checked in my initial code. It is still in its infancy with only basic support for a few tags and I've already logged a number of issues to work on (most notably, writing some test cases). James, if you're still interested in collaborating, perhaps you could take a look before we begin to talk, - It's structured similar to the dojo plugin at the moment. I added a few notes to the wiki. Included in the static files is the publish/subscribe framework. It is very light and can be used elsewhere. I'll submit to jquery eventually.
WRT to the widgets & jQuery plugins, the principle I've taken so far is to only use widgets that are part of the official jQuery-UI distro, that is, not to use any third party plugins. These are all fairly stable and should make the maintenance easier as Wes pointed out. At the moment, the jQuery-UI<http://docs.jquery.com/UI>widgets only include -- accordion menu, datepicker, dialog, tabbed pane, progress bar and slider (most of which don't make sense for this effort) -- but there are quite a number more in their pipepline<http://jqueryui.pbwiki.com/>and a few (including autocomplete) slated for the next jQuery-UI release (1.7). I agree that form submission should be high on the prioprity list. jQuery makes this quite simple, and in the current code, like with the dojo plugins, the anchor and submit tags take a 'formId' which already does this but without validation at the moment. I'll add this to the issue list... Wes, with regards, to the list management work-flow you described, are you thinking of a specialized widget that handles all this or just a framework that makes this very easy? If it's the latter then I think we're almost there already. With the current subscribe/publish framework, several ajax-request handler hooks are pre-defined for the major element event (for example, before, after, success, error, always for the 'click' load event of a div) and hooking in to *any *event 'callback' is easy. For extensibility, we can easily expose *all *events for an element to this, effectively allowing users to make publish and subscribe to *any * triggered event. On an aside, have you definitively decided to move the json interceptor and result-type into the core? - Eric 2009/2/24 Musachy Barroso <musa...@gmail.com> > Validation with JQuery should not be hard using the JSON validation > interceptor. This could be a good time to improve how the tags are > laid out to support adding/removing validation errors, Dave already > brought this up before and I think he did some changes already. > > musachy > > On Tue, Feb 24, 2009 at 11:17 AM, Wes Wannemacher <w...@wantii.com> wrote: > > On Mon, Feb 23, 2009 at 4:26 PM, Obinna <obi...@gmail.com> wrote: > >> 2009/2/23 Musachy Barroso <musa...@gmail.com> > >> > >>> > I definitely agree that a thoughtful design is the right starting > place. > >>> > Taking this to the extreme, one thing that I mentioned in my earlier > post > >>> > (without too much thought) was that perhaps some kind of standardized > >>> > specification for binding ajax features to standard struts tags > >>> (including > >>> > perhaps standardized widget tags - which may not be functional > without > >>> the > >>> > plugin) would be something worth thinking about as there are an > >>> increasing > >>> > number of struts-ajax library integration each with their own > integration > >>> > mechanisms and syntax. Given the variety of ajax implementations, > this > >>> might > >>> > be ambitious at the moment, but definitely worth a thought. This > would > >>> > probably take the form of some kind of standardized <bind/> tag spec > with > >>> > specified behaviour for implementations. > >>> > > >>> > >>> I think we should keep simple, and down to JQuery. I don't think it is > >>> worth the effort to go with some generic interface where multiple > >>> libraries can be plugged in. IMO that would add more complexity, lots > >>> of bugs and zillions of questions on the mailing lists(just supporting > >>> one library has been hard). I would say the same thing about the > >>> widgets, adding anything else beyond the jquery datepicker would be > >>> too much. > >> > >> > >> I agree. In addition to the datepicker, I think the tabbed pane widget > is > >> quite useful (I have already implemented it actually). I'd also like to > see > >> an autocompleter, but there is no native jQuery-UI widget for it yet > (though > >> a couple of strong candidates) and I remember the dojo autocompleter > being a > >> bit of a headache. > > > > I'm not completely convinced that the tabbedpanel is necessary... One > > thing I think we might want to consider is to avoid JQuery's plugin's > > unless they are absolutely necessary. Keeping ourselves close to > > JQuery proper may save us in maintenance down the line. That being > > said, there are elements available as plugins that provide > > functionality that we will want or need (better datepickers). > > > > > >>> > >>> > At the moment, I have taken the other route and integrated a few > jquery > >>> > ajax-enabled tags, but it shouldn't be too much work to switch these > to a > >>> > <bind/> tag implementation. So far, I have integrated the div, > anchor, > >>> > submit and tabbed pane tags (using a custom head tag to inject jquery > >>> > dependencies). I have NOT implemented the full set of tag attributes > for > >>> > these that dojo provided, opting to start with the minimal, critical > >>> > attributes first. For the binding I have implemented a very > lightweight > >>> > custom publish/subscribe jQuery extension framework which is one of > the > >>> few > >>> > things I really liked about the dojo framework. (I'll be sharing this > >>> once > >>> > on jquery as well once well tested) > >>> > > >>> > >>> Topics is one of the things that would be very nice to have, and I > >>> agree that we should start very small. > >>> > >> > >> Subscription/publishing using topics is provided in the jquery-subcribe > >> framework I've put together and heavily used by the generated jquery > code. > >> This is included in js files injected by head tag > > > > That's good that you've already got something in the works. This is > > one of the pieces that JQuery misses, that would make it fit well > > within struts. > > > >> > >> > >>> > >>> > Perhaps surprisingly, I have currently implemented the templates > using > >>> the > >>> > javatemplates plugin (not yet freemarker), simply because I've been > too > >>> lazy > >>> > to pick up the freemarker template syntax which I'm not very familiar > >>> with > >>> > yet (this might be a great starting place for some collaborative > help). > >>> > >>> I really like JQuery's one-liners, so maybe it won't be that hard to > >>> read in java code, if it get complex then I'd suggest swtiching to > >>> FreeMarker. > >>> > >> > >> Not excessively complex at the moment but getting there. Will implement > with > >> freemarker soon i hope. > >> > >> > > > > Another point I'd like to make is that I think a first stab would be > > to make a plugin that will enable AJAX form submission with > > validation. It's an easy task, but it is one of the most common > > use-cases. In the "old" days of struts2, you could ajax validation, > > just by adding 'theme="ajax"'. Althought I don't think it's worthwhile > > to strive for that sort of interoperability, it would be nice to have > > a set of form tags and a convention that allows a simple > > list-add|edit|delete-list workflow. Using a subscribe/publish/notify > > type of paradigm on the (preferably JSON) responses of each request, > > would allow users to hook their own handlers into each event. > > > > Here is how I see the work -> > > > > 0. have a head tag to include the necessary stuff > > 1. create a tag for retrieving and then exposing data... This would > > allow you to hook a handler to the response. I would use this to > > generate the list > > 2. create a form tag and handlers for validation errors. This would > > require a bit of massaging of the JSON results (IMO). Generally, the > > client has no idea what happened on the server (response code of > > action method / validation status). > > 3. create form elements that support the validation error messages. > > > > -Wes > > > > > > > > -- > > Wes Wannemacher > > Author - Struts 2 In Practice > > Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more > > http://www.manning.com/wannemacher > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > > For additional commands, e-mail: dev-h...@struts.apache.org > > > > > > > > -- > "Hey you! Would you help me to carry the stone?" Pink Floyd > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > >
