On 01/07/12 14:58, Emmanuel Bernard wrote:
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.
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
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 :)
sounds good to me as well. So are you thinking of a JSon export
like Ed mentioned earlier?
And if so, would it be relevant to create a "Reference "Implementation"
syntax is actually usable).
If we go one step further, we could make it like dialects in Hibernate
how easy/hard it would be to do it.
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
the client side web framework wire this altogether.
12) What JSF needs to specify in addition to the Trinidad Client Side
* 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?)
* 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.
* 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
* This key is resolved both in a "server" bundle and a "client"
bundle. If a key cannot be found in the "client" bundle, the
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
* 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
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
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:
> 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 :).
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).
> beanvalidation-dev mailing list
beanvalidation-dev mailing list