Validation :: Mirror server-side constraints to client-side

[virtualeyes]

By default it seems that form posts are processed server-side, which necessitates a trip to the server when client-side validation could trap invalid fields and save bandwidth/reduce load.

Not sure about Rails, but I believe that M$ has server-client validation coupling with MVC3.

Would be excellent if we had grails constraints, including custom validators, mirrored to JS validation methods.

Probably a pipe dream for now, so will implement client-side separately...

[sergiomichels]

Maybe mapping the constraints to a jquery plugin?

On Fri, Jul 29, 2011 at 7:11 PM, virtualeyes <[hidden email]> wrote:

By default it seems that form posts are processed server-side, which
necessitates a trip to the server when client-side validation could trap
invalid fields and save bandwidth/reduce load.

Not sure about Rails, but I believe that M$ has server-client validation
coupling with MVC3.

Would be excellent if we had grails constraints, including custom
validators, mirrored to JS validation methods.

Probably a pipe dream for now, so will implement client-side separately...

--
View this message in context: http://grails.1312388.n4.nabble.com/Validation-Mirror-server-side-constraints-to-client-side-tp3705448p3705448.html
Sent from the Grails - user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[Daniel Henrique Alves Lima]

  I don't think it is a dream. Even Struts :-P has something like this.

http://struts.apache.org/1.2.4/userGuide/dev_validator.html
http://struts.apache.org/1.2.4/userGuide/struts-html.html#javascript
http://commons.apache.org/validator/


virtualeyes wrote:

> By default it seems that form posts are processed server-side, which
> necessitates a trip to the server when client-side validation could trap
> invalid fields and save bandwidth/reduce load.
>
> Not sure about Rails, but I believe that M$ has server-client validation
> coupling with MVC3.
>
> Would be excellent if we had grails constraints, including custom
> validators, mirrored to JS validation methods.
>
> Probably a pipe dream for now, so will implement client-side separately...
>
>
>  

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Daniel Henrique Alves Lima-2]

  How about: http://www.grails.org/plugin/javascript-validator?

Daniel Henrique Alves Lima wrote:

> I don't think it is a dream. Even Struts :-P has something like this.
>
> http://struts.apache.org/1.2.4/userGuide/dev_validator.html
> http://struts.apache.org/1.2.4/userGuide/struts-html.html#javascript
> http://commons.apache.org/validator/
>
>
> virtualeyes wrote:
>> By default it seems that form posts are processed server-side, which
>> necessitates a trip to the server when client-side validation could trap
>> invalid fields and save bandwidth/reduce load.
>>
>> Not sure about Rails, but I believe that M$ has server-client validation
>> coupling with MVC3.
>>
>> Would be excellent if we had grails constraints, including custom
>> validators, mirrored to JS validation methods.
>> Probably a pipe dream for now, so will implement client-side
>> separately...
>>
>>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[virtualeyes]

Right, well, as far as Grails is concerned, as I see it there are a couple of issues to address to mirror the excellent server-side validation to client-side:

1) i18N
Need to pass locale-specific validation text and field label to client-side JS method

2) Form integration
as part of scaffolding process, or manually, onSubmit() attribute needs to reference applicable common JS validation methods on a per field basis.  For example, if you have domain Foo with String bar and constraints size:1..15, then the onSubmit could be in pseudo code:

<g:form ..... onSubmit="jFormValidate(bar|validRange(locale.invalid.range.message, i18N.foo.bar.label, 1, 15))"> 

where property|jsMethod is pipe delimited and jFormValidate is JS validation object that contains, range, maxLen, etc. constraint methods. As I intend to work in Grails (TBD, I may be, yuck, laying out GSPs manually) i18N label would be database derived, as would formfield properties generated by the form builder.

Client-side you can of course jquery fade-in/out messages, highlight/scroll fields, etc. without needing to do anything server-side until the form is valid.

[Daniel Henrique Alves Lima-2]

  I *think* it can be done automatically in a (new?) plugin. Like I've
said before: Struts do/did it. Of course, it is/was more complex in
Struts than it should be in Grails.

Best regards,

Daniel.

virtualeyes wrote:

> Right, well, as far as Grails is concerned, as I see it there are a couple of
> issues to address to mirror the excellent server-side validation to
> client-side:
>
> 1) i18N
> Need to pass locale-specific validation text and field label to client-side
> JS method
>
> 2) Form integration
> as part of scaffolding process, or manually, onSubmit() attribute needs to
> reference applicable common JS validation methods on a per field basis.  For
> example, if you have domain Foo with String bar and constraints size:1..15,
> then the onSubmit could be in pseudo code:
>
> <g:form .....
> onSubmit="jFormValidate(bar|validRange(locale.invalid.range.message,
> i18N.foo.bar.label, 1, 15))">
>
> where property|jsMethod is pipe delimited and jFormValidate is JS validation
> object that contains, range, maxLen, etc. constraint methods. As I intend to
> work in Grails (TBD, I may be, yuck, laying out GSPs manually) i18N label
> would be database derived, as would formfield properties generated by the
> form builder.
>
> Client-side you can of course jquery fade-in/out messages, highlight/scroll
> fields, etc. without needing to do anything server-side until the form is
> valid.
>
> Hackity hackity hack it down the stream, life is but a dream
>
>  

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email