Hmm, I hadn't thought about the value change events yet. That would be
a problem. I first had the idea to plugin a custom LifeCycleImpl, that
does not invoke the validator of each component, but instead calls the
hibernate validator on each property, but the problem there is that
Hibernate Validator is best used to validate an entire bean in one go
(or at least, that's how I understand it).
Jurgen
Mario Ivankovits schreef:
Hi!
I do this in FacesFreeway too.
But here I also generate the required components and thus I can attach
any validator I want.
To have it cleanly integrated in the phases of jsf we have to instrument
the tree after it has been created (yes martin, I know this is a no-no
for the standard ;-) )
But you can create your own view-handler and process all UIInputs after
createView parse the binding get its annotations and attach an
appropiated validator.
This wont work with components e.g. within an table or any other
components where the reference of the binding is only reachable during
the encoding phase.
Its more often the case than you might think ;-)
Doing this after the validation phase - during update model is a hack,
isnt it? e.g. it will fire valueChanges where the value to be changed to
might be and invalid value, no?
Ciao,
Mario
There might be some overlap here with Seam-- we've already implemented
some of this.
Sylvain Vieujot wrote:
I agree, it would be very nice and avoid double validation code for
the hibernate users.
It would also prevent meaning less errors for the users and show the
exact problem.
Great idea !
Sylvain.
On Sat, 2006-03-11 at 17:45 +0100, Jurgen Lust wrote:
How about this approach?
1. You annotate your model classes with Hibernate Validator
annotations, for example @Range(min=10, max=20)
2. You don't put any validators in the JSPs
3. You implement a custom PropertyResolverImpl that does the
following:
1. set the property
2. perform the validation with HibernateValidator on the
property
3. if the value is invalid, set the property to its original
value and throw an EvaluationException
4. The JSP is rendered with a FacesMessage next to the
input, containing the Hibernate Validator error message.
Advantages:
* All validation is in 1 place, the model class, where it belongs
* Much cleaner JSP
Disadvantages:
* You completely bypass the JSF process validations phase,
however, since the custom PropertyResolver would reset the
property to its old value when a validation error occurs, this
would not really be a problem.
This approach would not work at the moment, or at least until
MYFACES-1157 is fixed.
Any ideas?
Jurgen
Jurgen Lust schreef:
Hi,
I've been playing around with Hibernate Annotations a bit, and
noticed that there is also something like the Hibernate Validator:
http://www.hibernate.org/hib_docs/annotations/reference/en/html/validator.html
This allows you to specify constraints on your model classes, using
jdk 5.0 annotations. Hibernate then automatically enforces these
contraints in the persistence tier of your application.
Now I was thinking that this could also be used with JSF. Instead
of putting all the JSF validation stuff in the JSPs, you should be
able to use those annotations in the validate phase.
Has anyone tried this yet? Would it be possible, and are there any
pitfalls?
regards,
Jurgen
|
