Re: [bv-dev] Javascript export of bean validation rules

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: