Depending on how you do this, it might also allow you to work in db
validation from non-Hibernate users who are also using JSR
220-compatible products, like OpenEJB and Cayenne, which are currently
in the Incubator.

On 3/13/06, Dennis Byrne <[EMAIL PROTECTED]> wrote:
> Would be cool if the annotations stayed w/in JSR 220.  For example, a lot us 
> already have this in our models
>
> @Column(name = "crew_id", unique = false, nullable = false, insertable = 
> true, updatable = true, length = 255, precision = 19, scale = 2)
>
> It would be weird, but it could be used by people NOT using ejb3 .
>
> Dennis Byrne
>
> >-----Original Message-----
> >From: Sylvain Vieujot [mailto:[EMAIL PROTECTED]
> >Sent: Monday, March 13, 2006 09:35 AM
> >To: 'MyFaces Development'
> >Subject: Re: hibernate validator
> >
> >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
> >>
> >>
> >
>
>
>

Reply via email to