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
