[bv-dev] Javascript export of bean validation rules

[Emmanuel Bernard]

Here are my thoughts on the subject,

I always had in mind that Bean Validation should export the right metadata so that web frameworks have the necessary data for client side validation.
My reasoning was that it is not BV's business to write a JavaScript validation framework and impose it to web frameworks. If we come up with something, it will
certainly look alien and badly integrated to web framework X. Even beyond that, HTML5 let's you define some of these constraints with the markup language
itself not requiring any javascript. What if people want to use jQuery's validation framework or any other one?

I'm happy to reopen the debate but I don't want us to daydream a JS framework that will end up being used by zero or maybe one web framework out there :)

See below the proposal Pete Muir, Gerhard and I wrote for client side JSF back in 2008. This proposal did not go further at the time because we felt it would be too much for a v1 of the JSF-BV integration.
It does not involve sending the metadata via JSON but rather specify how to write the piece of Javascript responsible to validate a given value for a given constraint and let the client side web framework wire this altogether.

Emmanuel


---
12) What JSF needs to specify in addition to the Trinidad Client Side
Validation Framework

* JSR-314 should map each a resource, accessed by a GET request, in
the javax.faces.valiator namespace, to a JS resource which implements
the constraint. I propose the following resource URLs (Roger Kitian,
does this match the JSF2 ajax stuff, or should we be using . rather /
to delimit packages?)
/<context-root>/javax/faces/validator/<validator-class-fqn>.js

For example:

/foo/javax/faces/validator/javax/validator/notNull.js
/foo/javax/faces/validator/javax/validator/length.js
/foo/javax/faces/validator/com/acme/validator/ukPostcode.js

* We propose a simple convention based system, where this JS is stored
in the correct package, and loaded by JSF. Thus the notNull.js would
be loaded by the classloader as javax/validator/notNull.js. This
removes the need to have any constraint registry

* The core implementation of a constraint in JS returns true/false.
Inline javascript will be to call the constraints.

* A JSR-314 implementation would be required to implement the built in
constraints in JSR-303 in JS.

* The Trinidad client side validation and conversion framework allows
the instance of the validator to describe:

- a number of JS imports (see extension (a)). A list of resources
using the schema described above is returned.

- some inline JS. A JS constructor function should be built
automatically by the JSF2 implementation, such that it calls the each
metadata type validators (which are imported). If any return false,
the function should create a TrFacesMessage (part of the Trinidad
client side validation and conversion framework), providing for
interpolation the piece of metadata which failed, the label and the
submitted value. As no two fields have identical sets of metadata
types, we need to build a unique function for each field. The
constructor function should have a unique name based on the client id
of the input component.


- A JS constructor, which passes in the values to be interpolated.
This would just call the unique constructor. OPEN ISSUE: we could
merge the above into this function call.


- The Model Validator would provide the value and a message to be
interpolated. Interpolation of parameters and the label would be done
on the server side, producing a semi-expanded string.


13) Error messages


* To accommodate contextual constraint messages that cannot be created
on the client side, we require the constraint to use a bundle key as
the message.

* This key is resolved both in a "server" bundle and a "client"
bundle. If a key cannot be found in the "client" bundle, the "server"
bundle is used.

* The locale to use will be determined on the server, by the selected
locale for the request.

* If the BV constraint is composed, then one JS validation is created
for each composing and composed constraint.

* If the BV constraint is composed but ought to generate a singe
error, then the rendered inline JS function calls all the composing
constraints.

* This approach works if only one possible message is generated per
constraint (BV allows you to give out multipple)
- If different messages can be generated by a given constraint, the
list of possible message keys will have to be exposed by the JS
constraint implementation. The eager resolution is now possible.
- If multiple messages can be generated by a given constraint at the
same time (ie several errors per constraint), then that's harder. I
imagine JSF could artificially concatenate. Does not seem great. OPEN
ISSUE.

14) Extensions to the Trinidad client side validation and conversion
framework needed for JSR303 integration:

(a) Alter the signature of ClientValidator:public String
getClientLibrarySource(FacesContext context); to
ClientValidator:public List<String>
getClientLibrarySource(FacesContext context); to allow multiple JS
files to be imported for use in this validator. JSF2 is clever enough
to detect duplicate JS imports and remove them I believe.


On 28 juin 2012, at 06:59, Michael Isvy wrote:

> Hi,
> I was discussing this topic with Emmanuel Bernard by email and Emmanuel suggested that we move this conversation to this mailing-list, so here I am  :).
> 
> The idea would be to propose a javascript export of the bean validation rules. In that way, it would become fairly easy to do "true client side validation" (that is: validation that does not require access to the server side until the form is completely valid, or nearly completely valid). 
> Many web technologies such as JSF, Spring MVC, Wicket, Tapestry... integrate with JSR 303. Providing such export would be of great help for users of those frameworks (or standard in the case of JSF).
> 
> Cheers,
>     Michael.
> 
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev