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


-- 
mfg

Mario Ivankovits - OPS EDV Vertriebsges.m.b.H.
Software Engineering
Michael-Bernhard-Gasse 10, A-1120 Wien
Tel.: +43-1-8938810
Fax: +43-1-8938810/3700
E-Mail: [EMAIL PROTECTED]
Skype: mario_ivankovits

Reply via email to