After our team meeting I gave emmanuel the transcript. He recalled a very similar conversation way back in 2008. Alex please review this and determine where this fits in. Many of the concepts are the same, although some of the details & JSF have changed.

Here is a except from a mail by Pete from the october 13h 2008 (older than I thought). This was designed by Pete and I and reviewed by a few of the BV and JSF EG.

D) TRUE CLIENT SIDE VALIDATION

10) Trinidad Client Side Validation framework

Standardize this in order to implement client side validation in JSF; with this, we can then support client side constraints from JSR-303. Further, the Trinidad client side validation and conversion would need some (simple) extensions [1] to work well with model validation. For the purposes of this discussion, let's refer to this as "Trinidad client side validation and conversion". IS THERE ANYONE WHO KNOWS THE TRINIDAD PROJECT WELL WHO CAN STEP UP TO PRODUCE THIS PROPOSAL?

11) What JSR-303 provides

* Bean Validator exposes metadata about a particular constraint. Constrains can be composed of other constraints, thus allowing other validation in other layers to be built up and allowing fine grained constraints.

* If you define your own constraints you can add compose it from built in constraints, and your own constraints. Constraints can be composed of constraints that are themselves compositions

With this information, we can provide client side validators that will validate all built in constraints to JSR303; provide some validation when people compose constraints from built-in constraints, and also allow people to write their own JS to implement custom constraints.

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.validator 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.