Andrey, Clearly the choice of JS framework is not the issue here. However, what I was looking for was a MooTools version of the jQuery script that Aaron Porter wrote that leverages the "field-metadata" tag and that is why I mentioned MooTools here.
Your suggestion however is very interesting and sounds very simple to implement and does solve the localization of error messages. However, I am concerned thought that doing an Ajax call per "each" field change will amount to a lot of extra server requests and may be a performance clog on a high traffic site. Did you ever consider limiting to 1 Ajax request on hitting form "submit"... basically a pre-validation to actual form submission? Thoughts??? --Nikolaos Andrey Listochkin wrote: > Hi, Nikolaos > > I don't think the choice of JS framework could affect validation in > any way. After all you do use ajax, don't you? :) > > Here's how we solved it in one of our projects: > > 1. On client side we add an event listener to each form field (we > listen for onChange event). > 2. This event listener does a plain vanilla ajax request. Something like: > > /my/action/bean?fieldName=User+Value&ajaxValidate=atrue > In our action bean we have fields with some validation rules and > (optionally) custom methods assigned. If we leave it as is it won't > handle our request correctly because some other fields might be > required. That's why .. > > 3. Our action bean implements ValidationErrorHandler [1] interface to > hijack the default validation handling mechanism. > 4. By the time handleValidationErrors method is called all validation > rules are already applied and ValidationErrors array is already filled > in. > 5. Inside this handleValidationErrors we check for ajaxValidate > parameter in request and if it's present we filter out validation > errors corresponding to filedName field. > 6. If no errors are found we return a JSON {status: 'ok'}. Otherwise > we return JSON with validation errors. > 7. On a client side aour Ajax callback function expects a JSON > response data. If JSON has any errors we show them to user. > > It's not really hard to implement ajax validation this way and it's > completely library-agnostic. In our project we use jQuery so I don't > show the code to you to avoid confusion. But if you follow the > guidelines that's going to be easy. > > Note that we still required to have a ajaxValidate handler defined in > our action bean. It's going to be invoked when the last field in a > form is being validated and is going to pass validation. This is > because in this case ValidationErrors array is empty and > handleValidationErrors isn't called. If this method isn't defined > Stripes will use a default handler - and it might be not something you > intend to. > > Cheers, > Andrey > > [1] > http://stripes.sourceforge.net/docs/current/javadoc/net/sourceforge/stripes/validation/ValidationErrorHandler.html > > > > On Mon, 15 Nov 2010 20:05:09 +0200, Nikolaos Giannopoulos > <nikol...@brightminds.org> wrote: > >> Hi, >> >> I noticed the following page which shows how to integrate Stripes w/ >> client side validation via JQuery: >> http://www.stripesframework.org/display/stripes/Validation+Reference#ValidationReference-Usingthe{{fieldmetadata}}tag >> >> >> >> Has anyone done anything similar w/ MooTools? >> >> If so, was it a rewrite of Aaron's code or did it hook into MooTools >> Form Validation? >> >> And if so - anything shared would be appreciated. >> >> We are debating whether to do this now (though are short on time - what >> else is new) but anything that accelerates that could help us and in >> turn we would post it back to the community. I also realize the effort >> isn't huge but JQuery notation is new to me and doing this right w/ >> MooTools and classes will result in a pretty extensive re-write I'm >> afraid. >> >> Lastly, this is probably a stretch but did anyone solve the localization >> issue in all of this i.e. localized error messages exist in resource >> bundles on the Stripes server side yet the messages need to be >> accessible to provide the correct message to the user... Ajax is one >> possibility... using a generic set of translated messages is another... >> but all don't appear optimal. >> >> Much Appreciated. >> >> --Nikolaos >> >> ------------------------------------------------------------------------------ >> >> >> Centralized Desktop Delivery: Dell and VMware Reference Architecture >> Simplifying enterprise desktop deployment and management using >> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end >> client virtualization framework. Read more! >> http://p.sf.net/sfu/dell-eql-dev2dev >> _______________________________________________ >> Stripes-users mailing list >> Stripes-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/stripes-users > > -- Nikolaos Giannopoulos Director of Information Technology BrightMinds Software Inc. e. nikol...@brightminds.org w. www.brightminds.org t. 1.613.822.1700 c. 1.613.797.0036 f. 1.613.822.1915 ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users