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

Reply via email to