You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Ryan Sonnek <ry...@gmail.com> on 2007/05/08 15:50:05 UTC
Re: Hibernate Validator integration?
I haven't heard anything on this thread for a while, and it seemed
really exciting. Has there been any progress on creating a wicket
validator that uses hibernate annotations? anything available in
wicket-stuff to take a look at?
On 4/25/07, Xavier Hanin <xa...@gmail.com> wrote:
> On 4/25/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > naah, we share this list with wicket-stuff. makes it easier.
> Ok, sorry, next time I'll just put a +1 to give my opinion, it will
> save a couple of emails :-)
>
> Xavier
>
> >
> > -igor
> >
> >
> > On 4/25/07, Xavier Hanin <xa...@gmail.com> wrote:
> > >
> > > On 4/25/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > why would our opinion matter? you are free to start a wicket-stuff
> > > project
> > > > to integrate whatever you want :)
> > > Agreed, but since Bruno posted on the dev mailing list, I thought he
> > > was more specifically asking opinion from the wicket team.
> > >
> > > Xavier
> > >
> > > >
> > > > -igor
> > > >
> > > >
> > > > On 4/25/07, Xavier Hanin <xa...@gmail.com> wrote:
> > > > >
> > > > > On 4/25/07, Bruno Borges <br...@gmail.com> wrote:
> > > > > > Sorry.. worst than Draft Review: JSR 303 is in Draft Ballot yet!! So
> > > > > it'll
> > > > > > take some time until a final specification for this under JPA. :(
> > > > > >
> > > > > > Let's continue with HV ? :D
> > > > > It seems reasonable to me, but the opinion from Wicket team would be
> > > > > much more valuable than mine.
> > > > >
> > > > > Xavier
> > > > > >
> > > > > > []'s
> > > > > > --
> > > > > > Bruno Borges
> > > > > > Summa Technologies Inc.
> > > > > > www.summa-tech.com
> > > > > > (48) 8404-1300
> > > > > > (11) 3055-2060
> > > > > >
> > > > > > On 4/25/07, Bruno Borges <br...@gmail.com> wrote:
> > > > > > >
> > > > > > > Hibernate Validation is related to JSR 303<
> > > > > http://jcp.org/en/jsr/detail?id=303>,
> > > > > > > which is in draft review yet... :(
> > > > > > > And most probably HV will be used as RI with changes to JPA for
> > > sure.
> > > > > > > But maybe it can start as a contrib project, what'd you think?
> > > > > > >
> > > > > > > []'s
> > > > > > > --
> > > > > > > Bruno Borges
> > > > > > > Summa Technologies Inc.
> > > > > > > www.summa-tech.com
> > > > > > > (48) 8404-1300
> > > > > > > (11) 3055-2060
> > > > > > >
> > > > > > > On 4/25/07, Xavier Hanin <xa...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > I haven't had time to check HV in depth for the moment but I've
> > > > > heard
> > > > > > > > good things about it, and was about to ask the same question as
> > > > > Bruno,
> > > > > > > > because I would be interested too in such a validator.
> > > > > > > >
> > > > > > > > Martijn, doesn't your proposition to rely on JPA spec instead of
> > > HV
> > > > > > > > imply to rewrite sg similar to what has been done in HV?
> > > > > > > >
> > > > > > > > Xavier
> > > > > > > >
> > > > > > > > On 4/25/07, Martijn Dashorst <ma...@gmail.com> wrote:
> > > > > > > > > I would most like want this to be built against the JPA spec
> > > > > instead
> > > > > > > > > of directly implementing Hibernate's validators. Then we can
> > > use
> > > > > it
> > > > > > > > > for toplink, hibernate, openjpa, etc. And it is Apache license
> > > > > > > > > friendly too.
> > > > > > > > >
> > > > > > > > > Martijn
> > > > > > > > >
> > > > > > > > > On 4/25/07, Bruno Borges < bruno.borges@gmail.com> wrote:
> > > > > > > > > > I was thinking of a Validator like the Ajax one. See this
> > > > > example:
> > > > > > > > > >
> > > > > > > > > > TextField email = new TextField("email");
> > > > > > > > > > email.add(new JPAValidator()); // or new JPAValidator(
> > > Pojo.class
> > > > > );
> > > > > > > > > >
> > > > > > > > > > And the class scans the Model for annotated properties and
> > > adds
> > > > > the
> > > > > > > > related
> > > > > > > > > > Wicket validators automatically. If the Model is a POJO not
> > > > > > > > annotated with
> > > > > > > > > > @Entity, its possible to use JPAValidator(Class clazz);.
> > > > > > > > > >
> > > > > > > > > > @EmailValidation // a custom HV email's annotation pattern
> > > > > > > > > > public String getEmail() { return email; }
> > > > > > > > > >
> > > > > > > > > > What you guys think about this? (I like to see the code I'd
> > > like
> > > > > to
> > > > > > > > use and
> > > > > > > > > > implement it around the examples... :D )
> > > > > > > > > >
> > > > > > > > > > []'s
> > > > > > > > > > --
> > > > > > > > > > Bruno Borges
> > > > > > > > > > Summa Technologies Inc.
> > > > > > > > > > www.summa-tech.com
> > > > > > > > > > (48) 8404-1300
> > > > > > > > > > (11) 3055-2060
> > > > > > > > > >
> > > > > > > > > > On 4/24/07, Eelco Hillenius < eelco.hillenius@gmail.com>
> > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > I've been thinking about it, haven't got around doing it.
> > > > > Should
> > > > > > > > be
> > > > > > > > > > > pretty easy to do, especially with our shiny new
> > > validators.
> > > > > Maybe
> > > > > > > > we
> > > > > > > > > > > can make this a shared effort?
> > > > > > > > > > >
> > > > > > > > > > > Eelco
> > > > > > > > > > >
> > > > > > > > > > > On 4/24/07, Bruno Borges <bruno.borges@gmail.com > wrote:
> > > > > > > > > > > > Has anybody made an integration between Wicket and
> > > Hibernate
> > > > > > > > Validator?
> > > > > > > > > > > HV
> > > > > > > > > > > > is probably going to be the reference implementation for
> > > JSR
> > > > > 303
> > > > > > > > and
> > > > > > > > > > > JBoss
> > > > > > > > > > > > Seams use it integrated with JSF. Looks cool...
> > > > > > > > > > > >
> > > > > > > > > > > > http://hibernate.org/412.html
> > > > > > > > > > > > http://jcp.org/en/jsr/detail?id=303
> > > > > > > > > > > >
> > > > > > > > > > > > Cheers
> > > > > > > > > > > > --
> > > > > > > > > > > > Bruno Borges
> > > > > > > > > > > > Summa Technologies Inc.
> > > > > > > > > > > > www.summa-tech.com
> > > > > > > > > > > > (48) 8404-1300
> > > > > > > > > > > > (11) 3055-2060
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Learn Wicket at ApacheCon Europe: http://apachecon.com
> > > > > > > > > Join the wicket community at irc.freenode.net: ##wicket
> > > > > > > > > Wicket 1.2.6 contains a very important fix. Download Wicket
> > > now!
> > > > > > > > > http://wicketframework.org
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
> > > > > > > > Manage your dependencies with Ivy!
> > > > > > > > http://incubator.apache.org/ivy/
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
> > > > > Manage your dependencies with Ivy!
> > > > > http://incubator.apache.org/ivy/
> > > > >
> > > >
> > >
> > >
> > > --
> > > Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
> > > Manage your dependencies with Ivy!
> > > http://incubator.apache.org/ivy/
> > >
> >
>
>
> --
> Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
> Manage your dependencies with Ivy!
> http://incubator.apache.org/ivy/
>
Re: Hibernate Validator integration?
Posted by Igor Vaynberg <ig...@gmail.com>.
we will gladly accept a package.html to drop into wicket.validator :)
-igor
On 5/9/07, Jon Steelman <jo...@gmail.com> wrote:
>
> True but would it be a useful thing for a Wicket newbie to read in the
> javadoc? I always like it when a goal like this is made explicit- you know
> it is intended rather than a coincidence.
>
> Jon
>
>
> On 5/9/07, Igor Vaynberg <ig...@gmail.com> wrote:
> >
> > this change is only in 1.3. as far as documentation i dont know, its
> > pretty
> > obvious from the code. wicket.validator package doesnt have dependencies
> > on
> > any other package in wicket. maybe someday it will be its own little
> > project.
> >
> > -igor
> >
> >
> > On 5/9/07, Jon Steelman <jo...@gmail.com> wrote:
> > >
> > > Is this decoupling (& example of multiple use) concept expressed in
> the
> > > javadocs? I didn't see it on the 1.2.6 documentation. Would be good to
> > > capture it, maybe on the class documentation on IValidator and/or its
> > > package javadoc.
> > >
> > > Jon
> > >
> > >
> > > On 5/9/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > >
> > > > no. dont forget that the idea of IValidator is to be decoupled from
> > > > wicket,
> > > > to allow the reuse of validators in service layer. i do that all the
> > > time
> > > > now and it rocks! my service layer and my ui layer are validated by
> > the
> > > > same
> > > > code. adding ivalidator.getbehavior() will break all that nice
> > > decoupling.
> > > >
> > > > i always thought that something like this would work
> > > >
> > > > IClientSideValidator extends IValidator { /** rerturn a js func to
> > > > validate
> > > > the value */ CharSequence getValidationScript(); }
> > > >
> > > > then an instanceof check and you are done.
> > > >
> > > > -igor
> > > >
> > > >
> > > > On 5/9/07, Johan Compagner <jc...@gmail.com> wrote:
> > > > >
> > > > > a problem is that IBehavior is a pretty big interface
> > > > > And you work from the validator so its a lot of garbage a
> validator
> > > will
> > > > > get
> > > > > when it also implements IBehavior
> > > > > and we don't have multiply inheritance in java so it will be very
> > hard
> > > > to
> > > > > reuse stuff then
> > > > >
> > > > > That only is possible if we have this:
> > > > >
> > > > > IValidator.getBehavior()
> > > > >
> > > > > then the validator returns the behavior it also wants to have.
> > > > > then when add(IValidator) is called we check if it has a behavior
> > (or
> > > > its
> > > > > a
> > > > > IClientValidator or IValidatorBehavior whatever)
> > > > > and if it has one we call add(IBehavior) with that one
> automatically
> > > > >
> > > > > This way current validators can be come client side validators
> very
> > > > easily
> > > > > and one behavior can be reused multiply times that would be much
> > > harder
> > > > > if
> > > > > it really was one big class.
> > > > >
> > > > > johan
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > > > >
> > > > > > I'm not sure. It's smart to use a behavior for this, as that's
> > very
> > > > > > flexible and enables you to add client-side things (by adding
> > other
> > > > > > behaviors) easily.
> > > > > >
> > > > > > I'm not crazy about a behavior changing properties of
> components.
> > > It's
> > > > > > not wrong, but I think I'd prefer to let the component as is and
> > > make
> > > > > > a smart validator that just works on itself.
> > > > > >
> > > > > > I also think that the solution is a bit hackish. It's great to
> > make
> > > > > > things work quickly, but in this case I'd rather see whether we
> > can
> > > > > > find something generic, even if that would mean alterations in
> > > > > > Wicket's (internal) API as well.
> > > > > >
> > > > > > To do that, we have a couple of things to tackle:
> > > > > >
> > > > > > 1) Validators are currently server side all-the-way. But they
> > don't
> > > > > > have to be imho. If you combine a behavior and validator, you
> can
> > > > > > create a validator that checks on the server side (imo, *always*
> > do
> > > > > > that, even if you have the client side covered well) and
> > > additionally
> > > > > > write out some client side validation script. I see two ways to
> > > > > > achieve this:
> > > > > > a) Really make a combined class, but then we should extract a
> > > > > > combined interface for IValidator and IBehavior, so that you can
> > add
> > > > > > such a class to a component with just one method call
> > > > > > b) Introduce a limited IBehavior-like interface that can be
> > > extended
> > > > > > by IValidators and that is to be interpreted when rendering by
> > form
> > > > > > components.
> > > > > > My very strong preference is a), as I think it would be nice to
> be
> > > > > > able to do that anyway. The only people we'd break are the
> people
> > > who
> > > > > > override add(Behavior) now - something that we've warned against
> > to
> > > > > > start with - but we can find another way to support their use
> > case.
> > > > > >
> > > > > > 2) We should refine our concept of property models. It's still a
> > > > > > special case right now, though when you think of it, it's really
> a
> > > > > > very generic problem to solve, whether introspection is used or
> > not.
> > > > > > PropertyModels need to know the following things:
> > > > > > * The parent type of the property (e.g. Person). One tricky
> > thing
> > > > > > here is nested properties (like 'person.homeAddress.postalCode
> '),
> > > but
> > > > > > I'm sure we can find some solution.
> > > > > > * The type of the property ('name' is a string, 'dateOfBirth'
> a
> > > > date).
> > > > > > * The property name. Probably usually equal to the property
> > > > > > expression if one is available.
> > > > > >
> > > > > > In short, 1) would provide a means to let validators optionally
> > > > > > contribute client side code while still having a solid
> server-side
> > > > > > shield, and 2) provides all the means needed for introspecting
> on
> > > the
> > > > > > kind of validation that should be executed.
> > > > > >
> > > > > > WDYT?
> > > > > >
> > > > > > Eelco
> > > > > >
> > > > > >
> > > > > > On 5/9/07, Ryan Sonnek <ry...@gmail.com> wrote:
> > > > > > > Wow. After a flurry of research into this area, i've whipped
> > > > together
> > > > > > > a hibernate/wicket behavior that reads annotations and helps
> > > > configure
> > > > > > > the wicket component respectively.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://wicket-stuff.svn.sourceforge.net/viewvc/wicket-stuff/trunk/wicketstuff-hibernate-behavior/
> > > > > > >
> > > > > > > Essentially, right now it will auto configure a component by:
> > > > > > > * set component to be "required" when using NotNull annotation
> > > > > > > * add "maxlength" attribute when using Length annotation
> > > > > > >
> > > > > > > Still lots of work to be done:
> > > > > > > * attach client side javascript validation
> > > > > > > * maybe integrate into the wicket validation framework?
> > > > > > >
> > > > > > > I'd appreciate anyone interested to take a look and let me
> know
> > > what
> > > > > > they think.
> > > > > > >
> > > > > > > On 5/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > > > > > > > Ryan, lets finish this thread and move on to gTalk and
> > *talk*
> > > > > about
> > > > > > this.
> > > > > > > > > I'm adding you right now.
> > > > > > > >
> > > > > > > > Or even better... why don't you guys join the ##wicket IRC
> > > channel
> > > > > on
> > > > > > > > freenode.net? It's perfect for discussions like that, and
> > > changes
> > > > > are
> > > > > > > > you'll get some more people opinions in the process (44
> people
> > > > > hanging
> > > > > > > > out as I write this).
> > > > > > > >
> > > > > > > > > No, I dont have an account yet, and yes you can start the
> > > > project
> > > > > in
> > > > > > > > > wicket-stuff and after that, I'll ask you for permission.
> > > What'd
> > > > > you
> > > > > > think?
> > > > > > > >
> > > > > > > > Please reply with (or send me) your sourceforge id, and I'll
> > be
> > > > > happy
> > > > > > > > to add you to wicket-stuff.
> > > > > > > >
> > > > > > > > Eelco
> > > >
> > >
> >
>
Re: Hibernate Validator integration?
Posted by Jon Steelman <jo...@gmail.com>.
True but would it be a useful thing for a Wicket newbie to read in the
javadoc? I always like it when a goal like this is made explicit- you know
it is intended rather than a coincidence.
Jon
On 5/9/07, Igor Vaynberg <ig...@gmail.com> wrote:
>
> this change is only in 1.3. as far as documentation i dont know, its
> pretty
> obvious from the code. wicket.validator package doesnt have dependencies
> on
> any other package in wicket. maybe someday it will be its own little
> project.
>
> -igor
>
>
> On 5/9/07, Jon Steelman <jo...@gmail.com> wrote:
> >
> > Is this decoupling (& example of multiple use) concept expressed in the
> > javadocs? I didn't see it on the 1.2.6 documentation. Would be good to
> > capture it, maybe on the class documentation on IValidator and/or its
> > package javadoc.
> >
> > Jon
> >
> >
> > On 5/9/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > >
> > > no. dont forget that the idea of IValidator is to be decoupled from
> > > wicket,
> > > to allow the reuse of validators in service layer. i do that all the
> > time
> > > now and it rocks! my service layer and my ui layer are validated by
> the
> > > same
> > > code. adding ivalidator.getbehavior() will break all that nice
> > decoupling.
> > >
> > > i always thought that something like this would work
> > >
> > > IClientSideValidator extends IValidator { /** rerturn a js func to
> > > validate
> > > the value */ CharSequence getValidationScript(); }
> > >
> > > then an instanceof check and you are done.
> > >
> > > -igor
> > >
> > >
> > > On 5/9/07, Johan Compagner <jc...@gmail.com> wrote:
> > > >
> > > > a problem is that IBehavior is a pretty big interface
> > > > And you work from the validator so its a lot of garbage a validator
> > will
> > > > get
> > > > when it also implements IBehavior
> > > > and we don't have multiply inheritance in java so it will be very
> hard
> > > to
> > > > reuse stuff then
> > > >
> > > > That only is possible if we have this:
> > > >
> > > > IValidator.getBehavior()
> > > >
> > > > then the validator returns the behavior it also wants to have.
> > > > then when add(IValidator) is called we check if it has a behavior
> (or
> > > its
> > > > a
> > > > IClientValidator or IValidatorBehavior whatever)
> > > > and if it has one we call add(IBehavior) with that one automatically
> > > >
> > > > This way current validators can be come client side validators very
> > > easily
> > > > and one behavior can be reused multiply times that would be much
> > harder
> > > > if
> > > > it really was one big class.
> > > >
> > > > johan
> > > >
> > > >
> > > >
> > > >
> > > > On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > > >
> > > > > I'm not sure. It's smart to use a behavior for this, as that's
> very
> > > > > flexible and enables you to add client-side things (by adding
> other
> > > > > behaviors) easily.
> > > > >
> > > > > I'm not crazy about a behavior changing properties of components.
> > It's
> > > > > not wrong, but I think I'd prefer to let the component as is and
> > make
> > > > > a smart validator that just works on itself.
> > > > >
> > > > > I also think that the solution is a bit hackish. It's great to
> make
> > > > > things work quickly, but in this case I'd rather see whether we
> can
> > > > > find something generic, even if that would mean alterations in
> > > > > Wicket's (internal) API as well.
> > > > >
> > > > > To do that, we have a couple of things to tackle:
> > > > >
> > > > > 1) Validators are currently server side all-the-way. But they
> don't
> > > > > have to be imho. If you combine a behavior and validator, you can
> > > > > create a validator that checks on the server side (imo, *always*
> do
> > > > > that, even if you have the client side covered well) and
> > additionally
> > > > > write out some client side validation script. I see two ways to
> > > > > achieve this:
> > > > > a) Really make a combined class, but then we should extract a
> > > > > combined interface for IValidator and IBehavior, so that you can
> add
> > > > > such a class to a component with just one method call
> > > > > b) Introduce a limited IBehavior-like interface that can be
> > extended
> > > > > by IValidators and that is to be interpreted when rendering by
> form
> > > > > components.
> > > > > My very strong preference is a), as I think it would be nice to be
> > > > > able to do that anyway. The only people we'd break are the people
> > who
> > > > > override add(Behavior) now - something that we've warned against
> to
> > > > > start with - but we can find another way to support their use
> case.
> > > > >
> > > > > 2) We should refine our concept of property models. It's still a
> > > > > special case right now, though when you think of it, it's really a
> > > > > very generic problem to solve, whether introspection is used or
> not.
> > > > > PropertyModels need to know the following things:
> > > > > * The parent type of the property (e.g. Person). One tricky
> thing
> > > > > here is nested properties (like 'person.homeAddress.postalCode'),
> > but
> > > > > I'm sure we can find some solution.
> > > > > * The type of the property ('name' is a string, 'dateOfBirth' a
> > > date).
> > > > > * The property name. Probably usually equal to the property
> > > > > expression if one is available.
> > > > >
> > > > > In short, 1) would provide a means to let validators optionally
> > > > > contribute client side code while still having a solid server-side
> > > > > shield, and 2) provides all the means needed for introspecting on
> > the
> > > > > kind of validation that should be executed.
> > > > >
> > > > > WDYT?
> > > > >
> > > > > Eelco
> > > > >
> > > > >
> > > > > On 5/9/07, Ryan Sonnek <ry...@gmail.com> wrote:
> > > > > > Wow. After a flurry of research into this area, i've whipped
> > > together
> > > > > > a hibernate/wicket behavior that reads annotations and helps
> > > configure
> > > > > > the wicket component respectively.
> > > > > >
> > > > >
> > > >
> > >
> >
> http://wicket-stuff.svn.sourceforge.net/viewvc/wicket-stuff/trunk/wicketstuff-hibernate-behavior/
> > > > > >
> > > > > > Essentially, right now it will auto configure a component by:
> > > > > > * set component to be "required" when using NotNull annotation
> > > > > > * add "maxlength" attribute when using Length annotation
> > > > > >
> > > > > > Still lots of work to be done:
> > > > > > * attach client side javascript validation
> > > > > > * maybe integrate into the wicket validation framework?
> > > > > >
> > > > > > I'd appreciate anyone interested to take a look and let me know
> > what
> > > > > they think.
> > > > > >
> > > > > > On 5/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > > > > > > Ryan, lets finish this thread and move on to gTalk and
> *talk*
> > > > about
> > > > > this.
> > > > > > > > I'm adding you right now.
> > > > > > >
> > > > > > > Or even better... why don't you guys join the ##wicket IRC
> > channel
> > > > on
> > > > > > > freenode.net? It's perfect for discussions like that, and
> > changes
> > > > are
> > > > > > > you'll get some more people opinions in the process (44 people
> > > > hanging
> > > > > > > out as I write this).
> > > > > > >
> > > > > > > > No, I dont have an account yet, and yes you can start the
> > > project
> > > > in
> > > > > > > > wicket-stuff and after that, I'll ask you for permission.
> > What'd
> > > > you
> > > > > think?
> > > > > > >
> > > > > > > Please reply with (or send me) your sourceforge id, and I'll
> be
> > > > happy
> > > > > > > to add you to wicket-stuff.
> > > > > > >
> > > > > > > Eelco
> > >
> >
>
Re: Hibernate Validator integration?
Posted by Igor Vaynberg <ig...@gmail.com>.
this change is only in 1.3. as far as documentation i dont know, its pretty
obvious from the code. wicket.validator package doesnt have dependencies on
any other package in wicket. maybe someday it will be its own little
project.
-igor
On 5/9/07, Jon Steelman <jo...@gmail.com> wrote:
>
> Is this decoupling (& example of multiple use) concept expressed in the
> javadocs? I didn't see it on the 1.2.6 documentation. Would be good to
> capture it, maybe on the class documentation on IValidator and/or its
> package javadoc.
>
> Jon
>
>
> On 5/9/07, Igor Vaynberg <ig...@gmail.com> wrote:
> >
> > no. dont forget that the idea of IValidator is to be decoupled from
> > wicket,
> > to allow the reuse of validators in service layer. i do that all the
> time
> > now and it rocks! my service layer and my ui layer are validated by the
> > same
> > code. adding ivalidator.getbehavior() will break all that nice
> decoupling.
> >
> > i always thought that something like this would work
> >
> > IClientSideValidator extends IValidator { /** rerturn a js func to
> > validate
> > the value */ CharSequence getValidationScript(); }
> >
> > then an instanceof check and you are done.
> >
> > -igor
> >
> >
> > On 5/9/07, Johan Compagner <jc...@gmail.com> wrote:
> > >
> > > a problem is that IBehavior is a pretty big interface
> > > And you work from the validator so its a lot of garbage a validator
> will
> > > get
> > > when it also implements IBehavior
> > > and we don't have multiply inheritance in java so it will be very hard
> > to
> > > reuse stuff then
> > >
> > > That only is possible if we have this:
> > >
> > > IValidator.getBehavior()
> > >
> > > then the validator returns the behavior it also wants to have.
> > > then when add(IValidator) is called we check if it has a behavior (or
> > its
> > > a
> > > IClientValidator or IValidatorBehavior whatever)
> > > and if it has one we call add(IBehavior) with that one automatically
> > >
> > > This way current validators can be come client side validators very
> > easily
> > > and one behavior can be reused multiply times that would be much
> harder
> > > if
> > > it really was one big class.
> > >
> > > johan
> > >
> > >
> > >
> > >
> > > On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > >
> > > > I'm not sure. It's smart to use a behavior for this, as that's very
> > > > flexible and enables you to add client-side things (by adding other
> > > > behaviors) easily.
> > > >
> > > > I'm not crazy about a behavior changing properties of components.
> It's
> > > > not wrong, but I think I'd prefer to let the component as is and
> make
> > > > a smart validator that just works on itself.
> > > >
> > > > I also think that the solution is a bit hackish. It's great to make
> > > > things work quickly, but in this case I'd rather see whether we can
> > > > find something generic, even if that would mean alterations in
> > > > Wicket's (internal) API as well.
> > > >
> > > > To do that, we have a couple of things to tackle:
> > > >
> > > > 1) Validators are currently server side all-the-way. But they don't
> > > > have to be imho. If you combine a behavior and validator, you can
> > > > create a validator that checks on the server side (imo, *always* do
> > > > that, even if you have the client side covered well) and
> additionally
> > > > write out some client side validation script. I see two ways to
> > > > achieve this:
> > > > a) Really make a combined class, but then we should extract a
> > > > combined interface for IValidator and IBehavior, so that you can add
> > > > such a class to a component with just one method call
> > > > b) Introduce a limited IBehavior-like interface that can be
> extended
> > > > by IValidators and that is to be interpreted when rendering by form
> > > > components.
> > > > My very strong preference is a), as I think it would be nice to be
> > > > able to do that anyway. The only people we'd break are the people
> who
> > > > override add(Behavior) now - something that we've warned against to
> > > > start with - but we can find another way to support their use case.
> > > >
> > > > 2) We should refine our concept of property models. It's still a
> > > > special case right now, though when you think of it, it's really a
> > > > very generic problem to solve, whether introspection is used or not.
> > > > PropertyModels need to know the following things:
> > > > * The parent type of the property (e.g. Person). One tricky thing
> > > > here is nested properties (like 'person.homeAddress.postalCode'),
> but
> > > > I'm sure we can find some solution.
> > > > * The type of the property ('name' is a string, 'dateOfBirth' a
> > date).
> > > > * The property name. Probably usually equal to the property
> > > > expression if one is available.
> > > >
> > > > In short, 1) would provide a means to let validators optionally
> > > > contribute client side code while still having a solid server-side
> > > > shield, and 2) provides all the means needed for introspecting on
> the
> > > > kind of validation that should be executed.
> > > >
> > > > WDYT?
> > > >
> > > > Eelco
> > > >
> > > >
> > > > On 5/9/07, Ryan Sonnek <ry...@gmail.com> wrote:
> > > > > Wow. After a flurry of research into this area, i've whipped
> > together
> > > > > a hibernate/wicket behavior that reads annotations and helps
> > configure
> > > > > the wicket component respectively.
> > > > >
> > > >
> > >
> >
> http://wicket-stuff.svn.sourceforge.net/viewvc/wicket-stuff/trunk/wicketstuff-hibernate-behavior/
> > > > >
> > > > > Essentially, right now it will auto configure a component by:
> > > > > * set component to be "required" when using NotNull annotation
> > > > > * add "maxlength" attribute when using Length annotation
> > > > >
> > > > > Still lots of work to be done:
> > > > > * attach client side javascript validation
> > > > > * maybe integrate into the wicket validation framework?
> > > > >
> > > > > I'd appreciate anyone interested to take a look and let me know
> what
> > > > they think.
> > > > >
> > > > > On 5/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > > > > > Ryan, lets finish this thread and move on to gTalk and *talk*
> > > about
> > > > this.
> > > > > > > I'm adding you right now.
> > > > > >
> > > > > > Or even better... why don't you guys join the ##wicket IRC
> channel
> > > on
> > > > > > freenode.net? It's perfect for discussions like that, and
> changes
> > > are
> > > > > > you'll get some more people opinions in the process (44 people
> > > hanging
> > > > > > out as I write this).
> > > > > >
> > > > > > > No, I dont have an account yet, and yes you can start the
> > project
> > > in
> > > > > > > wicket-stuff and after that, I'll ask you for permission.
> What'd
> > > you
> > > > think?
> > > > > >
> > > > > > Please reply with (or send me) your sourceforge id, and I'll be
> > > happy
> > > > > > to add you to wicket-stuff.
> > > > > >
> > > > > > Eelco
> >
>
Re: Hibernate Validator integration?
Posted by Jon Steelman <jo...@gmail.com>.
Is this decoupling (& example of multiple use) concept expressed in the
javadocs? I didn't see it on the 1.2.6 documentation. Would be good to
capture it, maybe on the class documentation on IValidator and/or its
package javadoc.
Jon
On 5/9/07, Igor Vaynberg <ig...@gmail.com> wrote:
>
> no. dont forget that the idea of IValidator is to be decoupled from
> wicket,
> to allow the reuse of validators in service layer. i do that all the time
> now and it rocks! my service layer and my ui layer are validated by the
> same
> code. adding ivalidator.getbehavior() will break all that nice decoupling.
>
> i always thought that something like this would work
>
> IClientSideValidator extends IValidator { /** rerturn a js func to
> validate
> the value */ CharSequence getValidationScript(); }
>
> then an instanceof check and you are done.
>
> -igor
>
>
> On 5/9/07, Johan Compagner <jc...@gmail.com> wrote:
> >
> > a problem is that IBehavior is a pretty big interface
> > And you work from the validator so its a lot of garbage a validator will
> > get
> > when it also implements IBehavior
> > and we don't have multiply inheritance in java so it will be very hard
> to
> > reuse stuff then
> >
> > That only is possible if we have this:
> >
> > IValidator.getBehavior()
> >
> > then the validator returns the behavior it also wants to have.
> > then when add(IValidator) is called we check if it has a behavior (or
> its
> > a
> > IClientValidator or IValidatorBehavior whatever)
> > and if it has one we call add(IBehavior) with that one automatically
> >
> > This way current validators can be come client side validators very
> easily
> > and one behavior can be reused multiply times that would be much harder
> > if
> > it really was one big class.
> >
> > johan
> >
> >
> >
> >
> > On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > >
> > > I'm not sure. It's smart to use a behavior for this, as that's very
> > > flexible and enables you to add client-side things (by adding other
> > > behaviors) easily.
> > >
> > > I'm not crazy about a behavior changing properties of components. It's
> > > not wrong, but I think I'd prefer to let the component as is and make
> > > a smart validator that just works on itself.
> > >
> > > I also think that the solution is a bit hackish. It's great to make
> > > things work quickly, but in this case I'd rather see whether we can
> > > find something generic, even if that would mean alterations in
> > > Wicket's (internal) API as well.
> > >
> > > To do that, we have a couple of things to tackle:
> > >
> > > 1) Validators are currently server side all-the-way. But they don't
> > > have to be imho. If you combine a behavior and validator, you can
> > > create a validator that checks on the server side (imo, *always* do
> > > that, even if you have the client side covered well) and additionally
> > > write out some client side validation script. I see two ways to
> > > achieve this:
> > > a) Really make a combined class, but then we should extract a
> > > combined interface for IValidator and IBehavior, so that you can add
> > > such a class to a component with just one method call
> > > b) Introduce a limited IBehavior-like interface that can be extended
> > > by IValidators and that is to be interpreted when rendering by form
> > > components.
> > > My very strong preference is a), as I think it would be nice to be
> > > able to do that anyway. The only people we'd break are the people who
> > > override add(Behavior) now - something that we've warned against to
> > > start with - but we can find another way to support their use case.
> > >
> > > 2) We should refine our concept of property models. It's still a
> > > special case right now, though when you think of it, it's really a
> > > very generic problem to solve, whether introspection is used or not.
> > > PropertyModels need to know the following things:
> > > * The parent type of the property (e.g. Person). One tricky thing
> > > here is nested properties (like 'person.homeAddress.postalCode'), but
> > > I'm sure we can find some solution.
> > > * The type of the property ('name' is a string, 'dateOfBirth' a
> date).
> > > * The property name. Probably usually equal to the property
> > > expression if one is available.
> > >
> > > In short, 1) would provide a means to let validators optionally
> > > contribute client side code while still having a solid server-side
> > > shield, and 2) provides all the means needed for introspecting on the
> > > kind of validation that should be executed.
> > >
> > > WDYT?
> > >
> > > Eelco
> > >
> > >
> > > On 5/9/07, Ryan Sonnek <ry...@gmail.com> wrote:
> > > > Wow. After a flurry of research into this area, i've whipped
> together
> > > > a hibernate/wicket behavior that reads annotations and helps
> configure
> > > > the wicket component respectively.
> > > >
> > >
> >
> http://wicket-stuff.svn.sourceforge.net/viewvc/wicket-stuff/trunk/wicketstuff-hibernate-behavior/
> > > >
> > > > Essentially, right now it will auto configure a component by:
> > > > * set component to be "required" when using NotNull annotation
> > > > * add "maxlength" attribute when using Length annotation
> > > >
> > > > Still lots of work to be done:
> > > > * attach client side javascript validation
> > > > * maybe integrate into the wicket validation framework?
> > > >
> > > > I'd appreciate anyone interested to take a look and let me know what
> > > they think.
> > > >
> > > > On 5/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > > > > Ryan, lets finish this thread and move on to gTalk and *talk*
> > about
> > > this.
> > > > > > I'm adding you right now.
> > > > >
> > > > > Or even better... why don't you guys join the ##wicket IRC channel
> > on
> > > > > freenode.net? It's perfect for discussions like that, and changes
> > are
> > > > > you'll get some more people opinions in the process (44 people
> > hanging
> > > > > out as I write this).
> > > > >
> > > > > > No, I dont have an account yet, and yes you can start the
> project
> > in
> > > > > > wicket-stuff and after that, I'll ask you for permission. What'd
> > you
> > > think?
> > > > >
> > > > > Please reply with (or send me) your sourceforge id, and I'll be
> > happy
> > > > > to add you to wicket-stuff.
> > > > >
> > > > > Eelco
>
Re: Hibernate Validator integration?
Posted by Eelco Hillenius <ee...@gmail.com>.
Also, it's solvable, and we should focus on the concept first.
Eelco
On 5/10/07, Bruno Borges <br...@gmail.com> wrote:
> There's no removeValidator(), right? So, we dont have to care about
> behaviors added by validators.
>
> --
> Bruno Borges
> Summa Technologies Inc.
> www.summa-tech.com
> (48) 8404-1300
> (11) 3055-2060
>
> On 5/10/07, Igor Vaynberg <ig...@gmail.com> wrote:
> >
> > On 5/10/07, Johan Compagner <jc...@gmail.com> wrote:
> > >
> > > i find that class extremely ugly
> > > IValidator is a pretty simple interface but IBehavior not.
> > >
> > > And what does that solve? nothing i don't find it any cleaner
> >
> >
> > can you remove behaviors that validator has added? when your remove a
> > validator how will you know which behaviors were linked?
> >
> > And you have to add it twice.. or only as a valdiator and we add it also
> > as
> > > a validator??
> >
> >
> > no. if ivalidator implements ibehavior we only add it to behaviors. then
> > validate also iterates over behaviors and does instanceof ivalidator.
> >
> > (then you have to do that funny cast)
> >
> >
> > yes. this is the only con i see. like i said maybe we add a convineience
> > addvalidator(ivalidator) that will avoid the cast.
> >
> > -igor
> >
> >
> >
> > johan
> > >
> > >
> > >
> > > On 5/10/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > >
> > > > On 5/10/07, Johan Compagner <jc...@gmail.com> wrote:
> > > > >
> > > > > and i don't like that
> > > > > that is mixing 2 classes as once thing
> > > > > that means no reuse what so ever. This just makes big copy paste
> > > > actions.
> > > >
> > > >
> > > > lets see a concrete example of this. i dont see how my
> > > > ValidatorWithBehavior
> > > > thing prevents any reuse.
> > > >
> > > > -igor
> > > >
> > >
> >
>
Re: Hibernate Validator integration?
Posted by Igor Vaynberg <ig...@gmail.com>.
im sure there will be one in a near future.
-igor
On 5/10/07, Bruno Borges <br...@gmail.com> wrote:
>
> There's no removeValidator(), right? So, we dont have to care about
> behaviors added by validators.
>
> --
> Bruno Borges
> Summa Technologies Inc.
> www.summa-tech.com
> (48) 8404-1300
> (11) 3055-2060
>
> On 5/10/07, Igor Vaynberg <ig...@gmail.com> wrote:
> >
> > On 5/10/07, Johan Compagner <jc...@gmail.com> wrote:
> > >
> > > i find that class extremely ugly
> > > IValidator is a pretty simple interface but IBehavior not.
> > >
> > > And what does that solve? nothing i don't find it any cleaner
> >
> >
> > can you remove behaviors that validator has added? when your remove a
> > validator how will you know which behaviors were linked?
> >
> > And you have to add it twice.. or only as a valdiator and we add it also
> > as
> > > a validator??
> >
> >
> > no. if ivalidator implements ibehavior we only add it to behaviors. then
> > validate also iterates over behaviors and does instanceof ivalidator.
> >
> > (then you have to do that funny cast)
> >
> >
> > yes. this is the only con i see. like i said maybe we add a convineience
> > addvalidator(ivalidator) that will avoid the cast.
> >
> > -igor
> >
> >
> >
> > johan
> > >
> > >
> > >
> > > On 5/10/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > >
> > > > On 5/10/07, Johan Compagner <jc...@gmail.com> wrote:
> > > > >
> > > > > and i don't like that
> > > > > that is mixing 2 classes as once thing
> > > > > that means no reuse what so ever. This just makes big copy paste
> > > > actions.
> > > >
> > > >
> > > > lets see a concrete example of this. i dont see how my
> > > > ValidatorWithBehavior
> > > > thing prevents any reuse.
> > > >
> > > > -igor
> > > >
> > >
> >
>
Re: Hibernate Validator integration?
Posted by Bruno Borges <br...@gmail.com>.
There's no removeValidator(), right? So, we dont have to care about
behaviors added by validators.
--
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(48) 8404-1300
(11) 3055-2060
On 5/10/07, Igor Vaynberg <ig...@gmail.com> wrote:
>
> On 5/10/07, Johan Compagner <jc...@gmail.com> wrote:
> >
> > i find that class extremely ugly
> > IValidator is a pretty simple interface but IBehavior not.
> >
> > And what does that solve? nothing i don't find it any cleaner
>
>
> can you remove behaviors that validator has added? when your remove a
> validator how will you know which behaviors were linked?
>
> And you have to add it twice.. or only as a valdiator and we add it also
> as
> > a validator??
>
>
> no. if ivalidator implements ibehavior we only add it to behaviors. then
> validate also iterates over behaviors and does instanceof ivalidator.
>
> (then you have to do that funny cast)
>
>
> yes. this is the only con i see. like i said maybe we add a convineience
> addvalidator(ivalidator) that will avoid the cast.
>
> -igor
>
>
>
> johan
> >
> >
> >
> > On 5/10/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > >
> > > On 5/10/07, Johan Compagner <jc...@gmail.com> wrote:
> > > >
> > > > and i don't like that
> > > > that is mixing 2 classes as once thing
> > > > that means no reuse what so ever. This just makes big copy paste
> > > actions.
> > >
> > >
> > > lets see a concrete example of this. i dont see how my
> > > ValidatorWithBehavior
> > > thing prevents any reuse.
> > >
> > > -igor
> > >
> >
>
Re: Hibernate Validator integration?
Posted by Johan Compagner <jc...@gmail.com>.
> see my previous mail (i aksed the same thing to eelco)
> > just don't add the behavior to the behaviors
> > just in render also walk over the validators and get the behavior if it
> > has
> > one.
> > then if you remove the validator everything is gone.
>
>
> but where do you keep the reference? if you create a new one on every
> request then these behaviors cant have state!
getBehaviour shouldn't return everytime a new one
just the same thing. (it could be a new one if he wants thats up to the
validator)
but i see other problems comming because if validators also add stuff to the
> > tag
> > like onchange or onblur. Then what happens to the other behaviors (maybe
> > ajax)
> > that also wants to do something?
>
>
> this is a problem even now. basically we need to be careful and merge
> attributes instead of simply setting them (overwriting whatever was there
> before)
yeah but they are comming to bite us much much harder with client side
validation
people expect that when validation fails there rest is not called.
so on the client side it must be a thing we do specific for validators
You really don't want developers to merge that them selfs
how can they do that with all the standard (ajax) behaviors we have now??
If i attach a validator to a field (Range) that has clientside also build in
(on onchange)
and i also want a FormComponenUpdatingBehavior on it (on onchange)
then those should 'merge' automatically but the validator should go first
and if it fails the other behaviors shouldn't be called but only if it is ok
the form component
updating behavior should work.
johan
Re: Hibernate Validator integration?
Posted by Igor Vaynberg <ig...@gmail.com>.
On 5/10/07, Johan Compagner <jc...@gmail.com> wrote:
>
> >
> > can you remove behaviors that validator has added? when your remove a
> > validator how will you know which behaviors were linked?
>
>
> see my previous mail (i aksed the same thing to eelco)
> just don't add the behavior to the behaviors
> just in render also walk over the validators and get the behavior if it
> has
> one.
> then if you remove the validator everything is gone.
but where do you keep the reference? if you create a new one on every
request then these behaviors cant have state!
but i see other problems comming because if validators also add stuff to the
> tag
> like onchange or onblur. Then what happens to the other behaviors (maybe
> ajax)
> that also wants to do something?
this is a problem even now. basically we need to be careful and merge
attributes instead of simply setting them (overwriting whatever was there
before)
-igor
we are getting duplicate additions this way much much sooner.
> and the worse thing is, the developer itself doesn't really know that. It
> doesn't
> do the bind itself to "onchange" for the validator that is just under
> water
> happening.
>
> Or can we use the special wicket bind event for everything?
> But that i guess order is again also importand. Because i think validators
> should happen first
> before other things like ajax (formsubmit behavior...)
>
> johan
>
Re: Hibernate Validator integration?
Posted by Johan Compagner <jc...@gmail.com>.
>
> can you remove behaviors that validator has added? when your remove a
> validator how will you know which behaviors were linked?
see my previous mail (i aksed the same thing to eelco)
just don't add the behavior to the behaviors
just in render also walk over the validators and get the behavior if it has
one.
then if you remove the validator everything is gone.
but i see other problems comming because if validators also add stuff to the
tag
like onchange or onblur. Then what happens to the other behaviors (maybe
ajax)
that also wants to do something?
we are getting duplicate additions this way much much sooner.
and the worse thing is, the developer itself doesn't really know that. It
doesn't
do the bind itself to "onchange" for the validator that is just under water
happening.
Or can we use the special wicket bind event for everything?
But that i guess order is again also importand. Because i think validators
should happen first
before other things like ajax (formsubmit behavior...)
johan
Re: Hibernate Validator integration?
Posted by Igor Vaynberg <ig...@gmail.com>.
On 5/10/07, Johan Compagner <jc...@gmail.com> wrote:
>
> i find that class extremely ugly
> IValidator is a pretty simple interface but IBehavior not.
>
> And what does that solve? nothing i don't find it any cleaner
can you remove behaviors that validator has added? when your remove a
validator how will you know which behaviors were linked?
And you have to add it twice.. or only as a valdiator and we add it also as
> a validator??
no. if ivalidator implements ibehavior we only add it to behaviors. then
validate also iterates over behaviors and does instanceof ivalidator.
(then you have to do that funny cast)
yes. this is the only con i see. like i said maybe we add a convineience
addvalidator(ivalidator) that will avoid the cast.
-igor
johan
>
>
>
> On 5/10/07, Igor Vaynberg <ig...@gmail.com> wrote:
> >
> > On 5/10/07, Johan Compagner <jc...@gmail.com> wrote:
> > >
> > > and i don't like that
> > > that is mixing 2 classes as once thing
> > > that means no reuse what so ever. This just makes big copy paste
> > actions.
> >
> >
> > lets see a concrete example of this. i dont see how my
> > ValidatorWithBehavior
> > thing prevents any reuse.
> >
> > -igor
> >
>
Re: Hibernate Validator integration?
Posted by Johan Compagner <jc...@gmail.com>.
i find that class extremely ugly
IValidator is a pretty simple interface but IBehavior not.
And what does that solve? nothing i don't find it any cleaner
And you have to add it twice.. or only as a valdiator and we add it also as
a validator??
(then you have to do that funny cast)
And as a said in my other mail. If we have Valdiator.getBehavior()
then that class you want is perfectly possible. just return this...
johan
On 5/10/07, Igor Vaynberg <ig...@gmail.com> wrote:
>
> On 5/10/07, Johan Compagner <jc...@gmail.com> wrote:
> >
> > and i don't like that
> > that is mixing 2 classes as once thing
> > that means no reuse what so ever. This just makes big copy paste
> actions.
>
>
> lets see a concrete example of this. i dont see how my
> ValidatorWithBehavior
> thing prevents any reuse.
>
> -igor
>
Re: Hibernate Validator integration?
Posted by Igor Vaynberg <ig...@gmail.com>.
On 5/10/07, Johan Compagner <jc...@gmail.com> wrote:
>
> and i don't like that
> that is mixing 2 classes as once thing
> that means no reuse what so ever. This just makes big copy paste actions.
lets see a concrete example of this. i dont see how my ValidatorWithBehavior
thing prevents any reuse.
-igor
Re: Hibernate Validator integration?
Posted by Bruno Borges <br...@gmail.com>.
[x] All above
--
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(48) 8404-1300
(11) 3055-2060
On 5/10/07, Johan Compagner <jc...@gmail.com> wrote:
>
> If we are talking about client side validators: then you want support for
> 2
> behaviors that are attached to "blur" and "onchange" ?
> or one client side javascript check and an ajax call to the behavior?
>
> Or are there others that you have in mind?
>
> johan
>
>
> On 5/10/07, Bruno Borges <br...@gmail.com> wrote:
> >
> > What if we want to have in one IValidator, more than one IBehavior? just
> > wondering... :)
> >
> > This could be important and usefull, if in one Validator two _very
> simple_
> > behaviors are needed, and they need to be keep separated with each
> other.
> >
> > []'s
> > --
> > Bruno Borges
> > Summa Technologies Inc.
> > www.summa-tech.com
> > (48) 8404-1300
> > (11) 3055-2060
> >
> > On 5/10/07, Johan Compagner <jc...@gmail.com> wrote:
> > >
> > > and i don't like that
> > > that is mixing 2 classes as once thing
> > > that means no reuse what so ever. This just makes big copy paste
> > actions.
> > >
> > > it should be possible to seperate IValidator and IBehavior
> > implementations
> > > else if i want to use an IValidator i have to reimplement it
> > > yes ofcourse i can make my behavior implement also IValidator
> > > and then passthrough everything of the IValidtor to the real validator
> > > that
> > > is again a delegate.
> > >
> > > we just don't have multiply inheritance in java..
> > >
> > > having a IValidator provide a IBehavior is much nicer in my eyes
> > >
> > > johan
> > >
> > >
> > > On 5/10/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > >
> > > > hrm. after looking at it i dont like it :|
> > > >
> > > > ivalidator is a pretty simple interface. why not simply allow a
> > behavior
> > > > to
> > > > implement it
> > > >
> > > > add(ivalidator v) {
> > > > if (v instanceof ibehavior) { add((ibehavior)v); }
> > > > ...
> > > > }
> > > >
> > > > so now a behavior can implement ivalidator. the problem that
> > > > ibehaviorprovider tries to solve is to allow one to glue any
> > ivalidator
> > > > with
> > > > any ibehavior. well, that can very simply be done with an adapter
> > class
> > > > that
> > > > simply delegates to the right delegate
> > > >
> > > > class ValidatorWithBehavior implements IBehavior,IValidator{
> > > > private IBehavior behavior;
> > > > private IValidator validator;
> > > > public ValidatorWithBehavior(IValidator v, IBehavior b) {
> > > > this.behavior=b;this.validator=v;
> > > > }
> > > > ...delegating methods...
> > > > }
> > > >
> > > > this way we do not need IBehaviorProvider. we make behaviors and
> > > > validators
> > > > more flexible because a behavior can also be a validator. there is
> no
> > > > removeBehavior/removeValidator problem because they are the same
> > > instance
> > > > and only exist once.
> > > >
> > > > my two cents
> > > >
> > > > -igor
> > > >
> > > >
> > > > On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > > >
> > > > > > no. dont forget that the idea of IValidator is to be decoupled
> > from
> > > > > wicket,
> > > > > > to allow the reuse of validators in service layer. i do that all
> > the
> > > > > time
> > > > > > now and it rocks! my service layer and my ui layer are validated
> > by
> > > > the
> > > > > same
> > > > > > code. adding ivalidator.getbehavior() will break all that nice
> > > > > decoupling.
> > > > > >
> > > > > > i always thought that something like this would work
> > > > > >
> > > > > > IClientSideValidator extends IValidator { /** rerturn a js func
> to
> > > > > validate
> > > > > > the value */ CharSequence getValidationScript(); }
> > > > >
> > > > > /**
> > > > > * Validator that provides a behavior, e.g. for rendering
> client-side
> > > or
> > > > > ajax
> > > > > * validation. This interface can be implemented by either
> > > > > * {@link IValidator validators} or {@link IFormValidator form
> > > > validators}.
> > > > > */
> > > > > public interface IBehaviorProvider extends IClusterable
> > > > > {
> > > > > /**
> > > > > * Gets behavior for validation.
> > > > > *
> > > > > * @param component
> > > > > * component currently using the validator
> > > > > * @return The behavior, which can be used for rendering
> e.g
> > .
> > > > > */
> > > > > IBehavior getValidationBehavior(Component component);
> > > > > }
> > > > >
> > > > > same here, instanceof check and ready. Not extra code as how to
> > > > > interpret it, and all the flexibility that behaviors provide.
> > > > >
> > > > > Eelco
> > > > >
> > > >
> > >
> >
>
Re: Hibernate Validator integration?
Posted by Johan Compagner <jc...@gmail.com>.
If we are talking about client side validators: then you want support for 2
behaviors that are attached to "blur" and "onchange" ?
or one client side javascript check and an ajax call to the behavior?
Or are there others that you have in mind?
johan
On 5/10/07, Bruno Borges <br...@gmail.com> wrote:
>
> What if we want to have in one IValidator, more than one IBehavior? just
> wondering... :)
>
> This could be important and usefull, if in one Validator two _very simple_
> behaviors are needed, and they need to be keep separated with each other.
>
> []'s
> --
> Bruno Borges
> Summa Technologies Inc.
> www.summa-tech.com
> (48) 8404-1300
> (11) 3055-2060
>
> On 5/10/07, Johan Compagner <jc...@gmail.com> wrote:
> >
> > and i don't like that
> > that is mixing 2 classes as once thing
> > that means no reuse what so ever. This just makes big copy paste
> actions.
> >
> > it should be possible to seperate IValidator and IBehavior
> implementations
> > else if i want to use an IValidator i have to reimplement it
> > yes ofcourse i can make my behavior implement also IValidator
> > and then passthrough everything of the IValidtor to the real validator
> > that
> > is again a delegate.
> >
> > we just don't have multiply inheritance in java..
> >
> > having a IValidator provide a IBehavior is much nicer in my eyes
> >
> > johan
> >
> >
> > On 5/10/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > >
> > > hrm. after looking at it i dont like it :|
> > >
> > > ivalidator is a pretty simple interface. why not simply allow a
> behavior
> > > to
> > > implement it
> > >
> > > add(ivalidator v) {
> > > if (v instanceof ibehavior) { add((ibehavior)v); }
> > > ...
> > > }
> > >
> > > so now a behavior can implement ivalidator. the problem that
> > > ibehaviorprovider tries to solve is to allow one to glue any
> ivalidator
> > > with
> > > any ibehavior. well, that can very simply be done with an adapter
> class
> > > that
> > > simply delegates to the right delegate
> > >
> > > class ValidatorWithBehavior implements IBehavior,IValidator{
> > > private IBehavior behavior;
> > > private IValidator validator;
> > > public ValidatorWithBehavior(IValidator v, IBehavior b) {
> > > this.behavior=b;this.validator=v;
> > > }
> > > ...delegating methods...
> > > }
> > >
> > > this way we do not need IBehaviorProvider. we make behaviors and
> > > validators
> > > more flexible because a behavior can also be a validator. there is no
> > > removeBehavior/removeValidator problem because they are the same
> > instance
> > > and only exist once.
> > >
> > > my two cents
> > >
> > > -igor
> > >
> > >
> > > On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > >
> > > > > no. dont forget that the idea of IValidator is to be decoupled
> from
> > > > wicket,
> > > > > to allow the reuse of validators in service layer. i do that all
> the
> > > > time
> > > > > now and it rocks! my service layer and my ui layer are validated
> by
> > > the
> > > > same
> > > > > code. adding ivalidator.getbehavior() will break all that nice
> > > > decoupling.
> > > > >
> > > > > i always thought that something like this would work
> > > > >
> > > > > IClientSideValidator extends IValidator { /** rerturn a js func to
> > > > validate
> > > > > the value */ CharSequence getValidationScript(); }
> > > >
> > > > /**
> > > > * Validator that provides a behavior, e.g. for rendering client-side
> > or
> > > > ajax
> > > > * validation. This interface can be implemented by either
> > > > * {@link IValidator validators} or {@link IFormValidator form
> > > validators}.
> > > > */
> > > > public interface IBehaviorProvider extends IClusterable
> > > > {
> > > > /**
> > > > * Gets behavior for validation.
> > > > *
> > > > * @param component
> > > > * component currently using the validator
> > > > * @return The behavior, which can be used for rendering e.g
> .
> > > > */
> > > > IBehavior getValidationBehavior(Component component);
> > > > }
> > > >
> > > > same here, instanceof check and ready. Not extra code as how to
> > > > interpret it, and all the flexibility that behaviors provide.
> > > >
> > > > Eelco
> > > >
> > >
> >
>
Re: Hibernate Validator integration?
Posted by Eelco Hillenius <ee...@gmail.com>.
> Instead of:
> public IBehavior newValidationBehavior(Component component)
>
> Have:
> public void addBehavior(Component component)
I don't dislike it, but I see one practical problem. If we'd ever
support removing validators, we wouldn't know which behaviors would
have to be removed. So for this interface to work, we really need add
*and* remove defined.
Eelco
Re: Hibernate Validator integration?
Posted by Al Maw <wi...@almaw.com>.
Bruno Borges wrote:
> What if we want to have in one IValidator, more than one IBehavior? just
> wondering... :)
>
> This could be important and usefull, if in one Validator two _very simple_
> behaviors are needed, and they need to be keep separated with each other.
>
> []'s
We could have a method that adds behaviours, rather than provides them.
Instead of:
public IBehavior newValidationBehavior(Component component)
Have:
public void addBehavior(Component component)
At that point, I'm wondering if there's any point calling it
addBehavior() - surely we should just have a much more generic hook
instead, where you can add IBehaviors, or do anything else you want?
Something like:
public void onAdd(Component component)
So Component#add(IValidator validator) calls validator.onAdd(this);
What do you think?
Al
Re: Hibernate Validator integration?
Posted by Bruno Borges <br...@gmail.com>.
What if we want to have in one IValidator, more than one IBehavior? just
wondering... :)
This could be important and usefull, if in one Validator two _very simple_
behaviors are needed, and they need to be keep separated with each other.
[]'s
--
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(48) 8404-1300
(11) 3055-2060
On 5/10/07, Johan Compagner <jc...@gmail.com> wrote:
>
> and i don't like that
> that is mixing 2 classes as once thing
> that means no reuse what so ever. This just makes big copy paste actions.
>
> it should be possible to seperate IValidator and IBehavior implementations
> else if i want to use an IValidator i have to reimplement it
> yes ofcourse i can make my behavior implement also IValidator
> and then passthrough everything of the IValidtor to the real validator
> that
> is again a delegate.
>
> we just don't have multiply inheritance in java..
>
> having a IValidator provide a IBehavior is much nicer in my eyes
>
> johan
>
>
> On 5/10/07, Igor Vaynberg <ig...@gmail.com> wrote:
> >
> > hrm. after looking at it i dont like it :|
> >
> > ivalidator is a pretty simple interface. why not simply allow a behavior
> > to
> > implement it
> >
> > add(ivalidator v) {
> > if (v instanceof ibehavior) { add((ibehavior)v); }
> > ...
> > }
> >
> > so now a behavior can implement ivalidator. the problem that
> > ibehaviorprovider tries to solve is to allow one to glue any ivalidator
> > with
> > any ibehavior. well, that can very simply be done with an adapter class
> > that
> > simply delegates to the right delegate
> >
> > class ValidatorWithBehavior implements IBehavior,IValidator{
> > private IBehavior behavior;
> > private IValidator validator;
> > public ValidatorWithBehavior(IValidator v, IBehavior b) {
> > this.behavior=b;this.validator=v;
> > }
> > ...delegating methods...
> > }
> >
> > this way we do not need IBehaviorProvider. we make behaviors and
> > validators
> > more flexible because a behavior can also be a validator. there is no
> > removeBehavior/removeValidator problem because they are the same
> instance
> > and only exist once.
> >
> > my two cents
> >
> > -igor
> >
> >
> > On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > >
> > > > no. dont forget that the idea of IValidator is to be decoupled from
> > > wicket,
> > > > to allow the reuse of validators in service layer. i do that all the
> > > time
> > > > now and it rocks! my service layer and my ui layer are validated by
> > the
> > > same
> > > > code. adding ivalidator.getbehavior() will break all that nice
> > > decoupling.
> > > >
> > > > i always thought that something like this would work
> > > >
> > > > IClientSideValidator extends IValidator { /** rerturn a js func to
> > > validate
> > > > the value */ CharSequence getValidationScript(); }
> > >
> > > /**
> > > * Validator that provides a behavior, e.g. for rendering client-side
> or
> > > ajax
> > > * validation. This interface can be implemented by either
> > > * {@link IValidator validators} or {@link IFormValidator form
> > validators}.
> > > */
> > > public interface IBehaviorProvider extends IClusterable
> > > {
> > > /**
> > > * Gets behavior for validation.
> > > *
> > > * @param component
> > > * component currently using the validator
> > > * @return The behavior, which can be used for rendering e.g.
> > > */
> > > IBehavior getValidationBehavior(Component component);
> > > }
> > >
> > > same here, instanceof check and ready. Not extra code as how to
> > > interpret it, and all the flexibility that behaviors provide.
> > >
> > > Eelco
> > >
> >
>
Re: Hibernate Validator integration?
Posted by Johan Compagner <jc...@gmail.com>.
> >
> > we just don't have multiply inheritance in java..
> Thank God we don't have multiple inheritance...
>
> Since these interfaces are so thin, creating a class that implements
> both interfaces and delgates to separate implementation classes should
> be pretty light weight.
>
and if you want that with the validator.getBehavior()
that is then simple just return this...
but if we combined it up front then we don't have another choice.
johan
Re: Hibernate Validator integration?
Posted by Ryan Sonnek <ry...@gmail.com>.
On 5/10/07, Johan Compagner <jc...@gmail.com> wrote:
> and i don't like that
> that is mixing 2 classes as once thing
> that means no reuse what so ever. This just makes big copy paste actions.
>
> it should be possible to seperate IValidator and IBehavior implementations
> else if i want to use an IValidator i have to reimplement it
> yes ofcourse i can make my behavior implement also IValidator
> and then passthrough everything of the IValidtor to the real validator that
> is again a delegate.
>
> we just don't have multiply inheritance in java..
Thank God we don't have multiple inheritance...
Since these interfaces are so thin, creating a class that implements
both interfaces and delgates to separate implementation classes should
be pretty light weight.
Re: Hibernate Validator integration?
Posted by Johan Compagner <jc...@gmail.com>.
and i don't like that
that is mixing 2 classes as once thing
that means no reuse what so ever. This just makes big copy paste actions.
it should be possible to seperate IValidator and IBehavior implementations
else if i want to use an IValidator i have to reimplement it
yes ofcourse i can make my behavior implement also IValidator
and then passthrough everything of the IValidtor to the real validator that
is again a delegate.
we just don't have multiply inheritance in java..
having a IValidator provide a IBehavior is much nicer in my eyes
johan
On 5/10/07, Igor Vaynberg <ig...@gmail.com> wrote:
>
> hrm. after looking at it i dont like it :|
>
> ivalidator is a pretty simple interface. why not simply allow a behavior
> to
> implement it
>
> add(ivalidator v) {
> if (v instanceof ibehavior) { add((ibehavior)v); }
> ...
> }
>
> so now a behavior can implement ivalidator. the problem that
> ibehaviorprovider tries to solve is to allow one to glue any ivalidator
> with
> any ibehavior. well, that can very simply be done with an adapter class
> that
> simply delegates to the right delegate
>
> class ValidatorWithBehavior implements IBehavior,IValidator{
> private IBehavior behavior;
> private IValidator validator;
> public ValidatorWithBehavior(IValidator v, IBehavior b) {
> this.behavior=b;this.validator=v;
> }
> ...delegating methods...
> }
>
> this way we do not need IBehaviorProvider. we make behaviors and
> validators
> more flexible because a behavior can also be a validator. there is no
> removeBehavior/removeValidator problem because they are the same instance
> and only exist once.
>
> my two cents
>
> -igor
>
>
> On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > > no. dont forget that the idea of IValidator is to be decoupled from
> > wicket,
> > > to allow the reuse of validators in service layer. i do that all the
> > time
> > > now and it rocks! my service layer and my ui layer are validated by
> the
> > same
> > > code. adding ivalidator.getbehavior() will break all that nice
> > decoupling.
> > >
> > > i always thought that something like this would work
> > >
> > > IClientSideValidator extends IValidator { /** rerturn a js func to
> > validate
> > > the value */ CharSequence getValidationScript(); }
> >
> > /**
> > * Validator that provides a behavior, e.g. for rendering client-side or
> > ajax
> > * validation. This interface can be implemented by either
> > * {@link IValidator validators} or {@link IFormValidator form
> validators}.
> > */
> > public interface IBehaviorProvider extends IClusterable
> > {
> > /**
> > * Gets behavior for validation.
> > *
> > * @param component
> > * component currently using the validator
> > * @return The behavior, which can be used for rendering e.g.
> > */
> > IBehavior getValidationBehavior(Component component);
> > }
> >
> > same here, instanceof check and ready. Not extra code as how to
> > interpret it, and all the flexibility that behaviors provide.
> >
> > Eelco
> >
>
Re: Hibernate Validator integration?
Posted by Bruno Borges <br...@gmail.com>.
Updated to revision
2123<http://wicket-stuff.svn.sourceforge.net/viewvc/wicket-stuff/trunk/wicketstuff-hibernate-behavior/src/main/java/org/wicketstuff/hibernate/validator/HibernateFormComponentValidator.java?revision=2123&view=markup>
[]'s
--
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(48) 8404-1300
(11) 3055-2060
On 5/10/07, Bruno Borges <br...@gmail.com> wrote:
>
> Have any of you seen this code<http://wicket-stuff.svn.sourceforge.net/viewvc/wicket-stuff/trunk/wicketstuff-hibernate-behavior/src/main/java/org/wicketstuff/hibernate/validator/HibernateFormComponentValidator.java?revision=2096&view=markup>I commited?
>
> There are some comments in it to discuss about.
>
> []'s
> --
> Bruno Borges
> Summa Technologies Inc.
> www.summa-tech.com
> (48) 8404-1300
> (11) 3055-2060
>
> On 5/10/07, Bruno Borges <br...@gmail.com> wrote:
> >
> > Cool. This can do the job. :)
> >
> > Dummy question: why newValidationBehavior and not just newBehavior ? :D
> >
> > []' s!
> > --
> > Bruno Borges
> > Summa Technologies Inc.
> > www.summa-tech.com
> > (48) 8404-1300
> > (11) 3055-2060
> >
> > On 5/10/07, Eelco Hillenius < eelco.hillenius@gmail.com> wrote:
> > >
> > > That's what we have/ had. You let IValidator extend IBehaviorProvider
> > > and then implement newValidatorBehavior.
> > >
> > > Eelco
> > >
> > > On 5/10/07, Bruno Borges < bruno.borges@gmail.com > wrote:
> > > > Why don't let IValidator has its own behavior if it wants to.
> > > >
> > > > IValidator.getBehavior()
> > > >
> > > > Behavior goes on the client-side, right? (I'm still a little
> > > confused about
> > > > all these interfaces...)
> > > >
> > > > Isn't this ok ? If not, why?
> > > >
> > > > --
> > > > Bruno Borges
> > > > Summa Technologies Inc.
> > > > www.summa-tech.com
> > > > (48) 8404-1300
> > > > (11) 3055-2060
> > > >
> > > > On 5/10/07, Igor Vaynberg <igor.vaynberg@gmail.com > wrote:
> > > > >
> > > > > On 5/10/07, Eelco Hillenius < eelco.hillenius@gmail.com> wrote:
> > > > > >
> > > > > > This is (of course) the first solution I worked on, and in fact
> > > the
> > > > > > solution I preferred up to yesterday (and maybe still prefer,
> > > not
> > > > > > sure). It needed some API changes though, as currently you can't
> > > have
> > > > > > a class that implements both interfaces and use add to call it.
> > > > >
> > > > >
> > > > > yes, i thought about this. doing add((IBehavior)foo) would be
> > > annoying. we
> > > > > need to think about how to solve it. maybe not have overloaded add
> > > > > methods,
> > > > > or have a convinience addValidator() in addition to both add()
> > > methods.
> > > > > dont
> > > > > know yet.
> > > > >
> > > > > What I
> > > > > > did was substract a common interface (in fact broken up in some
> > > sub
> > > > > > interfaces, so that potentially IValidators can detach for
> > > instance),
> > > > > > and change add's signature to use that. However, when I showed
> > > that to
> > > > > > Johan, he has two objections.
> > > > >
> > > > >
> > > > > i dont really like the above either. there isnt anything in common
> > > you can
> > > > > extract, they are orthogonal classes.
> > > > >
> > > > > One was that he didn't like the tight
> > > > > > coupling, and rather would have a situation where for one
> > > component,
> > > > > > it would return an ajax behavior, and for another an attribute
> > > > > > modifier etc. This is easier with the current implementation.
> > > > >
> > > > >
> > > > > not really, it is much easier with my adapter.
> > > > > add(new ValidatorAndBehavior(new MaxLengthValidator(5), new
> > > > > AjaxBehavior());
> > > > > add(new ValidatorAndBehavior(new MaxLengthValidator(5), new
> > > > > MaxLenSetter());
> > > > >
> > > > >
> > > > > otherwise you would have to have a subclass of maxlengthvalidator
> > > that
> > > > > allows you to set a behavior, or make it anonymous. the adapter
> > > can link
> > > > > arbitrary behaviors with less loc.
> > > > >
> > > > > Another
> > > > > > thing was - and I agree with that - that the common interface
> > > results
> > > > > > in the API being less discoverable, and also would potentially
> > > open up
> > > > > > our API for people coming up with weird mix-ins and expecting
> > > > > > everything to work. Like adding a validator to a non-form
> > > component
> > > > > > for instance.
> > > > >
> > > > >
> > > > > ah, but that we can check. when they add a behavior that is also a
> > > > > ivalidator to a non formcomponent we can throw an exception.
> > > > >
> > > > > -igor
> > > > >
> > > > >
> > > > >
> > > > > > Anyway, Johan convinced me this was a better approach. But we're
> > > still
> > > > > > in the discovery stage. Johan, you want to chip in with your 2
> > > c?
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Eelco
> > > > > >
> > > > >
> > > >
> > >
> >
> >
>
Re: Hibernate Validator integration?
Posted by Bruno Borges <br...@gmail.com>.
Have any of you seen this
code<http://wicket-stuff.svn.sourceforge.net/viewvc/wicket-stuff/trunk/wicketstuff-hibernate-behavior/src/main/java/org/wicketstuff/hibernate/validator/HibernateFormComponentValidator.java?revision=2096&view=markup>I
commited?
There are some comments in it to discuss about.
[]'s
--
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(48) 8404-1300
(11) 3055-2060
On 5/10/07, Bruno Borges <br...@gmail.com> wrote:
>
> Cool. This can do the job. :)
>
> Dummy question: why newValidationBehavior and not just newBehavior ? :D
>
> []' s!
> --
> Bruno Borges
> Summa Technologies Inc.
> www.summa-tech.com
> (48) 8404-1300
> (11) 3055-2060
>
> On 5/10/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > That's what we have/ had. You let IValidator extend IBehaviorProvider
> > and then implement newValidatorBehavior.
> >
> > Eelco
> >
> > On 5/10/07, Bruno Borges <bruno.borges@gmail.com > wrote:
> > > Why don't let IValidator has its own behavior if it wants to.
> > >
> > > IValidator.getBehavior()
> > >
> > > Behavior goes on the client-side, right? (I'm still a little confused
> > about
> > > all these interfaces...)
> > >
> > > Isn't this ok ? If not, why?
> > >
> > > --
> > > Bruno Borges
> > > Summa Technologies Inc.
> > > www.summa-tech.com
> > > (48) 8404-1300
> > > (11) 3055-2060
> > >
> > > On 5/10/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > >
> > > > On 5/10/07, Eelco Hillenius < eelco.hillenius@gmail.com> wrote:
> > > > >
> > > > > This is (of course) the first solution I worked on, and in fact
> > the
> > > > > solution I preferred up to yesterday (and maybe still prefer, not
> > > > > sure). It needed some API changes though, as currently you can't
> > have
> > > > > a class that implements both interfaces and use add to call it.
> > > >
> > > >
> > > > yes, i thought about this. doing add((IBehavior)foo) would be
> > annoying. we
> > > > need to think about how to solve it. maybe not have overloaded add
> > > > methods,
> > > > or have a convinience addValidator() in addition to both add()
> > methods.
> > > > dont
> > > > know yet.
> > > >
> > > > What I
> > > > > did was substract a common interface (in fact broken up in some
> > sub
> > > > > interfaces, so that potentially IValidators can detach for
> > instance),
> > > > > and change add's signature to use that. However, when I showed
> > that to
> > > > > Johan, he has two objections.
> > > >
> > > >
> > > > i dont really like the above either. there isnt anything in common
> > you can
> > > > extract, they are orthogonal classes.
> > > >
> > > > One was that he didn't like the tight
> > > > > coupling, and rather would have a situation where for one
> > component,
> > > > > it would return an ajax behavior, and for another an attribute
> > > > > modifier etc. This is easier with the current implementation.
> > > >
> > > >
> > > > not really, it is much easier with my adapter.
> > > > add(new ValidatorAndBehavior(new MaxLengthValidator(5), new
> > > > AjaxBehavior());
> > > > add(new ValidatorAndBehavior(new MaxLengthValidator(5), new
> > > > MaxLenSetter());
> > > >
> > > >
> > > > otherwise you would have to have a subclass of maxlengthvalidator
> > that
> > > > allows you to set a behavior, or make it anonymous. the adapter can
> > link
> > > > arbitrary behaviors with less loc.
> > > >
> > > > Another
> > > > > thing was - and I agree with that - that the common interface
> > results
> > > > > in the API being less discoverable, and also would potentially
> > open up
> > > > > our API for people coming up with weird mix-ins and expecting
> > > > > everything to work. Like adding a validator to a non-form
> > component
> > > > > for instance.
> > > >
> > > >
> > > > ah, but that we can check. when they add a behavior that is also a
> > > > ivalidator to a non formcomponent we can throw an exception.
> > > >
> > > > -igor
> > > >
> > > >
> > > >
> > > > > Anyway, Johan convinced me this was a better approach. But we're
> > still
> > > > > in the discovery stage. Johan, you want to chip in with your 2 c?
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > > Eelco
> > > > >
> > > >
> > >
> >
>
>
Re: Hibernate Validator integration?
Posted by Bruno Borges <br...@gmail.com>.
Cool. This can do the job. :)
Dummy question: why newValidationBehavior and not just newBehavior ? :D
[]' s!
--
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(48) 8404-1300
(11) 3055-2060
On 5/10/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> That's what we have/ had. You let IValidator extend IBehaviorProvider
> and then implement newValidatorBehavior.
>
> Eelco
>
> On 5/10/07, Bruno Borges <br...@gmail.com> wrote:
> > Why don't let IValidator has its own behavior if it wants to.
> >
> > IValidator.getBehavior()
> >
> > Behavior goes on the client-side, right? (I'm still a little confused
> about
> > all these interfaces...)
> >
> > Isn't this ok ? If not, why?
> >
> > --
> > Bruno Borges
> > Summa Technologies Inc.
> > www.summa-tech.com
> > (48) 8404-1300
> > (11) 3055-2060
> >
> > On 5/10/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > >
> > > On 5/10/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > >
> > > > This is (of course) the first solution I worked on, and in fact the
> > > > solution I preferred up to yesterday (and maybe still prefer, not
> > > > sure). It needed some API changes though, as currently you can't
> have
> > > > a class that implements both interfaces and use add to call it.
> > >
> > >
> > > yes, i thought about this. doing add((IBehavior)foo) would be
> annoying. we
> > > need to think about how to solve it. maybe not have overloaded add
> > > methods,
> > > or have a convinience addValidator() in addition to both add()
> methods.
> > > dont
> > > know yet.
> > >
> > > What I
> > > > did was substract a common interface (in fact broken up in some sub
> > > > interfaces, so that potentially IValidators can detach for
> instance),
> > > > and change add's signature to use that. However, when I showed that
> to
> > > > Johan, he has two objections.
> > >
> > >
> > > i dont really like the above either. there isnt anything in common you
> can
> > > extract, they are orthogonal classes.
> > >
> > > One was that he didn't like the tight
> > > > coupling, and rather would have a situation where for one component,
> > > > it would return an ajax behavior, and for another an attribute
> > > > modifier etc. This is easier with the current implementation.
> > >
> > >
> > > not really, it is much easier with my adapter.
> > > add(new ValidatorAndBehavior(new MaxLengthValidator(5), new
> > > AjaxBehavior());
> > > add(new ValidatorAndBehavior(new MaxLengthValidator(5), new
> > > MaxLenSetter());
> > >
> > >
> > > otherwise you would have to have a subclass of maxlengthvalidator that
> > > allows you to set a behavior, or make it anonymous. the adapter can
> link
> > > arbitrary behaviors with less loc.
> > >
> > > Another
> > > > thing was - and I agree with that - that the common interface
> results
> > > > in the API being less discoverable, and also would potentially open
> up
> > > > our API for people coming up with weird mix-ins and expecting
> > > > everything to work. Like adding a validator to a non-form component
> > > > for instance.
> > >
> > >
> > > ah, but that we can check. when they add a behavior that is also a
> > > ivalidator to a non formcomponent we can throw an exception.
> > >
> > > -igor
> > >
> > >
> > >
> > > > Anyway, Johan convinced me this was a better approach. But we're
> still
> > > > in the discovery stage. Johan, you want to chip in with your 2 c?
> > > >
> > >
> > >
> > >
> > >
> > > Eelco
> > > >
> > >
> >
>
Re: Hibernate Validator integration?
Posted by Eelco Hillenius <ee...@gmail.com>.
That's what we have/ had. You let IValidator extend IBehaviorProvider
and then implement newValidatorBehavior.
Eelco
On 5/10/07, Bruno Borges <br...@gmail.com> wrote:
> Why don't let IValidator has its own behavior if it wants to.
>
> IValidator.getBehavior()
>
> Behavior goes on the client-side, right? (I'm still a little confused about
> all these interfaces...)
>
> Isn't this ok ? If not, why?
>
> --
> Bruno Borges
> Summa Technologies Inc.
> www.summa-tech.com
> (48) 8404-1300
> (11) 3055-2060
>
> On 5/10/07, Igor Vaynberg <ig...@gmail.com> wrote:
> >
> > On 5/10/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > >
> > > This is (of course) the first solution I worked on, and in fact the
> > > solution I preferred up to yesterday (and maybe still prefer, not
> > > sure). It needed some API changes though, as currently you can't have
> > > a class that implements both interfaces and use add to call it.
> >
> >
> > yes, i thought about this. doing add((IBehavior)foo) would be annoying. we
> > need to think about how to solve it. maybe not have overloaded add
> > methods,
> > or have a convinience addValidator() in addition to both add() methods.
> > dont
> > know yet.
> >
> > What I
> > > did was substract a common interface (in fact broken up in some sub
> > > interfaces, so that potentially IValidators can detach for instance),
> > > and change add's signature to use that. However, when I showed that to
> > > Johan, he has two objections.
> >
> >
> > i dont really like the above either. there isnt anything in common you can
> > extract, they are orthogonal classes.
> >
> > One was that he didn't like the tight
> > > coupling, and rather would have a situation where for one component,
> > > it would return an ajax behavior, and for another an attribute
> > > modifier etc. This is easier with the current implementation.
> >
> >
> > not really, it is much easier with my adapter.
> > add(new ValidatorAndBehavior(new MaxLengthValidator(5), new
> > AjaxBehavior());
> > add(new ValidatorAndBehavior(new MaxLengthValidator(5), new
> > MaxLenSetter());
> >
> >
> > otherwise you would have to have a subclass of maxlengthvalidator that
> > allows you to set a behavior, or make it anonymous. the adapter can link
> > arbitrary behaviors with less loc.
> >
> > Another
> > > thing was - and I agree with that - that the common interface results
> > > in the API being less discoverable, and also would potentially open up
> > > our API for people coming up with weird mix-ins and expecting
> > > everything to work. Like adding a validator to a non-form component
> > > for instance.
> >
> >
> > ah, but that we can check. when they add a behavior that is also a
> > ivalidator to a non formcomponent we can throw an exception.
> >
> > -igor
> >
> >
> >
> > > Anyway, Johan convinced me this was a better approach. But we're still
> > > in the discovery stage. Johan, you want to chip in with your 2 c?
> > >
> >
> >
> >
> >
> > Eelco
> > >
> >
>
Re: Hibernate Validator integration?
Posted by Bruno Borges <br...@gmail.com>.
Why don't let IValidator has its own behavior if it wants to.
IValidator.getBehavior()
Behavior goes on the client-side, right? (I'm still a little confused about
all these interfaces...)
Isn't this ok ? If not, why?
--
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(48) 8404-1300
(11) 3055-2060
On 5/10/07, Igor Vaynberg <ig...@gmail.com> wrote:
>
> On 5/10/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > This is (of course) the first solution I worked on, and in fact the
> > solution I preferred up to yesterday (and maybe still prefer, not
> > sure). It needed some API changes though, as currently you can't have
> > a class that implements both interfaces and use add to call it.
>
>
> yes, i thought about this. doing add((IBehavior)foo) would be annoying. we
> need to think about how to solve it. maybe not have overloaded add
> methods,
> or have a convinience addValidator() in addition to both add() methods.
> dont
> know yet.
>
> What I
> > did was substract a common interface (in fact broken up in some sub
> > interfaces, so that potentially IValidators can detach for instance),
> > and change add's signature to use that. However, when I showed that to
> > Johan, he has two objections.
>
>
> i dont really like the above either. there isnt anything in common you can
> extract, they are orthogonal classes.
>
> One was that he didn't like the tight
> > coupling, and rather would have a situation where for one component,
> > it would return an ajax behavior, and for another an attribute
> > modifier etc. This is easier with the current implementation.
>
>
> not really, it is much easier with my adapter.
> add(new ValidatorAndBehavior(new MaxLengthValidator(5), new
> AjaxBehavior());
> add(new ValidatorAndBehavior(new MaxLengthValidator(5), new
> MaxLenSetter());
>
>
> otherwise you would have to have a subclass of maxlengthvalidator that
> allows you to set a behavior, or make it anonymous. the adapter can link
> arbitrary behaviors with less loc.
>
> Another
> > thing was - and I agree with that - that the common interface results
> > in the API being less discoverable, and also would potentially open up
> > our API for people coming up with weird mix-ins and expecting
> > everything to work. Like adding a validator to a non-form component
> > for instance.
>
>
> ah, but that we can check. when they add a behavior that is also a
> ivalidator to a non formcomponent we can throw an exception.
>
> -igor
>
>
>
> > Anyway, Johan convinced me this was a better approach. But we're still
> > in the discovery stage. Johan, you want to chip in with your 2 c?
> >
>
>
>
>
> Eelco
> >
>
Re: Hibernate Validator integration?
Posted by Igor Vaynberg <ig...@gmail.com>.
On 5/10/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> This is (of course) the first solution I worked on, and in fact the
> solution I preferred up to yesterday (and maybe still prefer, not
> sure). It needed some API changes though, as currently you can't have
> a class that implements both interfaces and use add to call it.
yes, i thought about this. doing add((IBehavior)foo) would be annoying. we
need to think about how to solve it. maybe not have overloaded add methods,
or have a convinience addValidator() in addition to both add() methods. dont
know yet.
What I
> did was substract a common interface (in fact broken up in some sub
> interfaces, so that potentially IValidators can detach for instance),
> and change add's signature to use that. However, when I showed that to
> Johan, he has two objections.
i dont really like the above either. there isnt anything in common you can
extract, they are orthogonal classes.
One was that he didn't like the tight
> coupling, and rather would have a situation where for one component,
> it would return an ajax behavior, and for another an attribute
> modifier etc. This is easier with the current implementation.
not really, it is much easier with my adapter.
add(new ValidatorAndBehavior(new MaxLengthValidator(5), new AjaxBehavior());
add(new ValidatorAndBehavior(new MaxLengthValidator(5), new MaxLenSetter());
otherwise you would have to have a subclass of maxlengthvalidator that
allows you to set a behavior, or make it anonymous. the adapter can link
arbitrary behaviors with less loc.
Another
> thing was - and I agree with that - that the common interface results
> in the API being less discoverable, and also would potentially open up
> our API for people coming up with weird mix-ins and expecting
> everything to work. Like adding a validator to a non-form component
> for instance.
ah, but that we can check. when they add a behavior that is also a
ivalidator to a non formcomponent we can throw an exception.
-igor
> Anyway, Johan convinced me this was a better approach. But we're still
> in the discovery stage. Johan, you want to chip in with your 2 c?
>
Eelco
>
Re: Hibernate Validator integration?
Posted by Eelco Hillenius <ee...@gmail.com>.
> hrm. after looking at it i dont like it :|
>
> ivalidator is a pretty simple interface. why not simply allow a behavior to
> implement it
>
> add(ivalidator v) {
> if (v instanceof ibehavior) { add((ibehavior)v); }
> ...
> }
>
> so now a behavior can implement ivalidator. the problem that
> ibehaviorprovider tries to solve is to allow one to glue any ivalidator with
> any ibehavior. well, that can very simply be done with an adapter class that
> simply delegates to the right delegate
>
> class ValidatorWithBehavior implements IBehavior,IValidator{
> private IBehavior behavior;
> private IValidator validator;
> public ValidatorWithBehavior(IValidator v, IBehavior b) {
> this.behavior=b;this.validator=v;
> }
> ...delegating methods...
> }
>
> this way we do not need IBehaviorProvider. we make behaviors and validators
> more flexible because a behavior can also be a validator. there is no
> removeBehavior/removeValidator problem because they are the same instance
> and only exist once.
This is (of course) the first solution I worked on, and in fact the
solution I preferred up to yesterday (and maybe still prefer, not
sure). It needed some API changes though, as currently you can't have
a class that implements both interfaces and use add to call it. What I
did was substract a common interface (in fact broken up in some sub
interfaces, so that potentially IValidators can detach for instance),
and change add's signature to use that. However, when I showed that to
Johan, he has two objections. One was that he didn't like the tight
coupling, and rather would have a situation where for one component,
it would return an ajax behavior, and for another an attribute
modifier etc. This is easier with the current implementation. Another
thing was - and I agree with that - that the common interface results
in the API being less discoverable, and also would potentially open up
our API for people coming up with weird mix-ins and expecting
everything to work. Like adding a validator to a non-form component
for instance.
Anyway, Johan convinced me this was a better approach. But we're still
in the discovery stage. Johan, you want to chip in with your 2 c?
Eelco
Re: Hibernate Validator integration?
Posted by Eelco Hillenius <ee...@gmail.com>.
> im talking about having access to component inside validate(ivaldiatable).
> it would take some ugly hacking to be able to do this with
> ibehaviorprovider, unless you do the same thing...let
> ibehaviorprovider.newbehavior return this.
Yeah, gotcha. Well, that's one of the things that I did like about my
first implementation: validators got a lot more powerful (at least
potentially).
Eelco
Re: Hibernate Validator integration?
Posted by Igor Vaynberg <ig...@gmail.com>.
im talking about having access to component inside validate(ivaldiatable).
it would take some ugly hacking to be able to do this with
ibehaviorprovider, unless you do the same thing...let
ibehaviorprovider.newbehavior return this.
-igor
On 5/10/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> On 5/10/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > actually another advantage of doing this, as far as hibernate validator
> > stuff goes, is that because it is a behavior and validator in one the
> > validator can get access to the component it is attached to via
> > behavior.bind().
>
> Not really a distinguishing feature though, as both the factory method
> gets the component passed in, and as the behavior gets added using the
> normal add(IBehavior) method, the behavior itself will get it's bind
> method called as well.
>
> Eelco
>
Re: Hibernate Validator integration?
Posted by Eelco Hillenius <ee...@gmail.com>.
On 5/10/07, Igor Vaynberg <ig...@gmail.com> wrote:
> actually another advantage of doing this, as far as hibernate validator
> stuff goes, is that because it is a behavior and validator in one the
> validator can get access to the component it is attached to via
> behavior.bind().
Not really a distinguishing feature though, as both the factory method
gets the component passed in, and as the behavior gets added using the
normal add(IBehavior) method, the behavior itself will get it's bind
method called as well.
Eelco
Re: Hibernate Validator integration?
Posted by Igor Vaynberg <ig...@gmail.com>.
actually another advantage of doing this, as far as hibernate validator
stuff goes, is that because it is a behavior and validator in one the
validator can get access to the component it is attached to via
behavior.bind().
-igor
On 5/10/07, Igor Vaynberg <ig...@gmail.com> wrote:
>
> hrm. after looking at it i dont like it :|
>
> ivalidator is a pretty simple interface. why not simply allow a behavior
> to implement it
>
> add(ivalidator v) {
> if (v instanceof ibehavior) { add((ibehavior)v); }
> ...
> }
>
> so now a behavior can implement ivalidator. the problem that
> ibehaviorprovider tries to solve is to allow one to glue any ivalidator with
> any ibehavior. well, that can very simply be done with an adapter class that
> simply delegates to the right delegate
>
> class ValidatorWithBehavior implements IBehavior,IValidator{
> private IBehavior behavior;
> private IValidator validator;
> public ValidatorWithBehavior(IValidator v, IBehavior b) {
> this.behavior=b;this.validator=v; }
> ...delegating methods...
> }
>
> this way we do not need IBehaviorProvider. we make behaviors and
> validators more flexible because a behavior can also be a validator. there
> is no removeBehavior/removeValidator problem because they are the same
> instance and only exist once.
>
> my two cents
>
> -igor
>
>
> On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > > no. dont forget that the idea of IValidator is to be decoupled from
> > wicket,
> > > to allow the reuse of validators in service layer. i do that all the
> > time
> > > now and it rocks! my service layer and my ui layer are validated by
> > the same
> > > code. adding ivalidator.getbehavior() will break all that nice
> > decoupling.
> > >
> > > i always thought that something like this would work
> > >
> > > IClientSideValidator extends IValidator { /** rerturn a js func to
> > validate
> > > the value */ CharSequence getValidationScript(); }
> >
> > /**
> > * Validator that provides a behavior, e.g. for rendering client-side or
> > ajax
> > * validation. This interface can be implemented by either
> > * {@link IValidator validators} or {@link IFormValidator form
> > validators}.
> > */
> > public interface IBehaviorProvider extends IClusterable
> > {
> > /**
> > * Gets behavior for validation.
> > *
> > * @param component
> > * component currently using the validator
> > * @return The behavior, which can be used for rendering e.g.
> > */
> > IBehavior getValidationBehavior(Component component);
> > }
> >
> > same here, instanceof check and ready. Not extra code as how to
> > interpret it, and all the flexibility that behaviors provide.
> >
> > Eelco
> >
>
>
Re: Hibernate Validator integration?
Posted by Igor Vaynberg <ig...@gmail.com>.
hrm. after looking at it i dont like it :|
ivalidator is a pretty simple interface. why not simply allow a behavior to
implement it
add(ivalidator v) {
if (v instanceof ibehavior) { add((ibehavior)v); }
...
}
so now a behavior can implement ivalidator. the problem that
ibehaviorprovider tries to solve is to allow one to glue any ivalidator with
any ibehavior. well, that can very simply be done with an adapter class that
simply delegates to the right delegate
class ValidatorWithBehavior implements IBehavior,IValidator{
private IBehavior behavior;
private IValidator validator;
public ValidatorWithBehavior(IValidator v, IBehavior b) {
this.behavior=b;this.validator=v;
}
...delegating methods...
}
this way we do not need IBehaviorProvider. we make behaviors and validators
more flexible because a behavior can also be a validator. there is no
removeBehavior/removeValidator problem because they are the same instance
and only exist once.
my two cents
-igor
On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> > no. dont forget that the idea of IValidator is to be decoupled from
> wicket,
> > to allow the reuse of validators in service layer. i do that all the
> time
> > now and it rocks! my service layer and my ui layer are validated by the
> same
> > code. adding ivalidator.getbehavior() will break all that nice
> decoupling.
> >
> > i always thought that something like this would work
> >
> > IClientSideValidator extends IValidator { /** rerturn a js func to
> validate
> > the value */ CharSequence getValidationScript(); }
>
> /**
> * Validator that provides a behavior, e.g. for rendering client-side or
> ajax
> * validation. This interface can be implemented by either
> * {@link IValidator validators} or {@link IFormValidator form validators}.
> */
> public interface IBehaviorProvider extends IClusterable
> {
> /**
> * Gets behavior for validation.
> *
> * @param component
> * component currently using the validator
> * @return The behavior, which can be used for rendering e.g.
> */
> IBehavior getValidationBehavior(Component component);
> }
>
> same here, instanceof check and ready. Not extra code as how to
> interpret it, and all the flexibility that behaviors provide.
>
> Eelco
>
Re: Hibernate Validator integration?
Posted by Eelco Hillenius <ee...@gmail.com>.
> I think IJavascriptValidator would be the
> best approach, as we need *javascript code somewhere in the client-side.
Behaviors can do that too, and more (including header contribution and
cooperating with components). So an optional interface with
getValidationBehavior or whatever is the way to go imho.
Eelco
Re: Hibernate Validator integration?
Posted by Bruno Borges <br...@gmail.com>.
Commited.
--
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(48) 8404-1300
(11) 3055-2060
On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> > Ok, updating myself in this thread... :D
> >
> > I think for this integration succeed, one important question must be
> > resolved:
> >
> > Q) What kind of validation this integration will process ?
> > a) wicket's internal validation
> > b) hibernate validator validation
> > c) behavior (like ryan implemented)
> >
> > I made this code yesterday and it ran ok:
> >
> > class ValidateForm extends Form {
> > public ValidateForm() {
> > super("form");
> > setModel(new CompoundPropertyModel(new User()));
> > add(new TextField("name"));
> > add(new TextField("email"));
> > add(new HibernateFormValidator(User.class));
> > }
> > }
> >
> > class HibernateFormValidator implements IFormValidator {
> > private ClassValidator validator;
> > public HibernateFormValidator(Class name) { validator = new
> > ClassValidator(name); }
> > public FormComponent[] getDependentFormComponents() { return
> null; }
> >
> > public void validate(Form form) {
> > Object object = form.getModelObject();
> > InvalidValue[] invalidValues = validator.getInvalidValues
> (object);
> >
> > for (InvalidValue iv : invalidValues) form.error(iv.getMessage
> ());
> > }
> > }
>
> I like this a lot. Can you commit that?
>
> Eelco
>
Re: Hibernate Validator integration?
Posted by Eelco Hillenius <ee...@gmail.com>.
> Ok, updating myself in this thread... :D
>
> I think for this integration succeed, one important question must be
> resolved:
>
> Q) What kind of validation this integration will process ?
> a) wicket's internal validation
> b) hibernate validator validation
> c) behavior (like ryan implemented)
>
> I made this code yesterday and it ran ok:
>
> class ValidateForm extends Form {
> public ValidateForm() {
> super("form");
> setModel(new CompoundPropertyModel(new User()));
> add(new TextField("name"));
> add(new TextField("email"));
> add(new HibernateFormValidator(User.class));
> }
> }
>
> class HibernateFormValidator implements IFormValidator {
> private ClassValidator validator;
> public HibernateFormValidator(Class name) { validator = new
> ClassValidator(name); }
> public FormComponent[] getDependentFormComponents() { return null; }
>
> public void validate(Form form) {
> Object object = form.getModelObject();
> InvalidValue[] invalidValues = validator.getInvalidValues(object);
>
> for (InvalidValue iv : invalidValues) form.error(iv.getMessage());
> }
> }
I like this a lot. Can you commit that?
Eelco
Re: Hibernate Validator integration?
Posted by Bruno Borges <br...@gmail.com>.
Ok, updating myself in this thread... :D
I think for this integration succeed, one important question must be
resolved:
Q) What kind of validation this integration will process ?
a) wicket's internal validation
b) hibernate validator validation
c) behavior (like ryan implemented)
I made this code yesterday and it ran ok:
class ValidateForm extends Form {
public ValidateForm() {
super("form");
setModel(new CompoundPropertyModel(new User()));
add(new TextField("name"));
add(new TextField("email"));
add(new HibernateFormValidator(User.class));
}
}
class HibernateFormValidator implements IFormValidator {
private ClassValidator validator;
public HibernateFormValidator(Class name) { validator = new
ClassValidator(name); }
public FormComponent[] getDependentFormComponents() { return null; }
public void validate(Form form) {
Object object = form.getModelObject();
InvalidValue[] invalidValues = validator.getInvalidValues(object);
for (InvalidValue iv : invalidValues) form.error(iv.getMessage());
}
}
This is an example if we choose option b. And Ryan's option c we have
already seen.
Imho, IFormValidator really should be used as a Form validation. :)
About client-side, this is much more critical 'cause IValidator is quite
generic (as Igor said before). I think IJavascriptValidator would be the
best approach, as we need *javascript code somewhere in the client-side.
Another thing: IJavascriptValidator can be used also in server-side as well,
and still be generic (been used in service layer) if the programmer eval
this validator with some API that runs Scripting Language - JSR
223<http://jcp.org/en/jsr/detail?id=223>.
So, one implementation only (in javascript) been evaluated at client and
server side. :) Of course, this shouldn't be required and the unique option
to IValidators, but I think is the best approach.
Any thoughts?
--
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(48) 8404-1300
(11) 3055-2060
On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> From my earlier email:
>
> > To do that, we have a couple of things to tackle:
> >
> > 1) Validators are currently server side all-the-way. But they don't
> > have to be imho. If you combine a behavior and validator, you can
> > create a validator that checks on the server side (imo, *always* do
> > that, even if you have the client side covered well) and additionally
> > write out some client side validation script.
>
> So, it's not directly related to solving hiberate validation
> integration, but I think this is a good time to look at how we can
> improve validation overall. Also, you were already adding a behavior,
> and this triggered me to look for a more generic solution. Doesn't
> have to let you hold back though. I think I can commit something in a
> few hours. Then if you want, Bruno and you can decide to pick this up
> or not.
>
> The second point I was making is more useful for this case. You need
> enough tools to introspect on models for your validation needs. Like I
> said before, I don't think I agree with using a behavior for
> validation. It might work well, especialy as the behavior(s) can add
> additional validators etc, but compared to just having one validator
> (on the form, which is the main case I'm thinking about), it's a lot
> more state for the same result.
>
> Eelco
>
> On 5/9/07, Ryan Sonnek <ry...@gmail.com> wrote:
> > I'm a little confused on how these changes would impact the hibernate
> > integration. anyone care to spell out how this changes the code?
> >
> > On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > Sounds good to me.
> > >
> > > Eelco
> > >
> > > On 5/9/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > what about making iformvalidator extend ivalidator. and
> ibehaviorprovider
> > > > extend ivalidator.
> > > >
> > > > in formvalidator validatable.value can be form.modelobject() and
> > > > validatable.error reports an error on form.
> > > >
> > > > -igor
> > > >
> > > >
> > > > On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > > >
> > > > > > no. dont forget that the idea of IValidator is to be decoupled
> from
> > > > > wicket,
> > > > > > to allow the reuse of validators in service layer. i do that all
> the
> > > > > time
> > > > > > now and it rocks! my service layer and my ui layer are validated
> by the
> > > > > same
> > > > > > code. adding ivalidator.getbehavior() will break all that nice
> > > > > decoupling.
> > > > > >
> > > > > > i always thought that something like this would work
> > > > > >
> > > > > > IClientSideValidator extends IValidator { /** rerturn a js func
> to
> > > > > validate
> > > > > > the value */ CharSequence getValidationScript(); }
> > > > >
> > > > > /**
> > > > > * Validator that provides a behavior, e.g. for rendering
> client-side or
> > > > > ajax
> > > > > * validation. This interface can be implemented by either
> > > > > * {@link IValidator validators} or {@link IFormValidator form
> validators}.
> > > > > */
> > > > > public interface IBehaviorProvider extends IClusterable
> > > > > {
> > > > > /**
> > > > > * Gets behavior for validation.
> > > > > *
> > > > > * @param component
> > > > > * component currently using the validator
> > > > > * @return The behavior, which can be used for rendering
> e.g.
> > > > > */
> > > > > IBehavior getValidationBehavior(Component component);
> > > > > }
> > > > >
> > > > > same here, instanceof check and ready. Not extra code as how to
> > > > > interpret it, and all the flexibility that behaviors provide.
> > > > >
> > > > > Eelco
> > > > >
> > > >
> > >
> >
>
Re: Hibernate Validator integration?
Posted by Eelco Hillenius <ee...@gmail.com>.
>From my earlier email:
> To do that, we have a couple of things to tackle:
>
> 1) Validators are currently server side all-the-way. But they don't
> have to be imho. If you combine a behavior and validator, you can
> create a validator that checks on the server side (imo, *always* do
> that, even if you have the client side covered well) and additionally
> write out some client side validation script.
So, it's not directly related to solving hiberate validation
integration, but I think this is a good time to look at how we can
improve validation overall. Also, you were already adding a behavior,
and this triggered me to look for a more generic solution. Doesn't
have to let you hold back though. I think I can commit something in a
few hours. Then if you want, Bruno and you can decide to pick this up
or not.
The second point I was making is more useful for this case. You need
enough tools to introspect on models for your validation needs. Like I
said before, I don't think I agree with using a behavior for
validation. It might work well, especialy as the behavior(s) can add
additional validators etc, but compared to just having one validator
(on the form, which is the main case I'm thinking about), it's a lot
more state for the same result.
Eelco
On 5/9/07, Ryan Sonnek <ry...@gmail.com> wrote:
> I'm a little confused on how these changes would impact the hibernate
> integration. anyone care to spell out how this changes the code?
>
> On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > Sounds good to me.
> >
> > Eelco
> >
> > On 5/9/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > what about making iformvalidator extend ivalidator. and ibehaviorprovider
> > > extend ivalidator.
> > >
> > > in formvalidator validatable.value can be form.modelobject() and
> > > validatable.error reports an error on form.
> > >
> > > -igor
> > >
> > >
> > > On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > >
> > > > > no. dont forget that the idea of IValidator is to be decoupled from
> > > > wicket,
> > > > > to allow the reuse of validators in service layer. i do that all the
> > > > time
> > > > > now and it rocks! my service layer and my ui layer are validated by the
> > > > same
> > > > > code. adding ivalidator.getbehavior() will break all that nice
> > > > decoupling.
> > > > >
> > > > > i always thought that something like this would work
> > > > >
> > > > > IClientSideValidator extends IValidator { /** rerturn a js func to
> > > > validate
> > > > > the value */ CharSequence getValidationScript(); }
> > > >
> > > > /**
> > > > * Validator that provides a behavior, e.g. for rendering client-side or
> > > > ajax
> > > > * validation. This interface can be implemented by either
> > > > * {@link IValidator validators} or {@link IFormValidator form validators}.
> > > > */
> > > > public interface IBehaviorProvider extends IClusterable
> > > > {
> > > > /**
> > > > * Gets behavior for validation.
> > > > *
> > > > * @param component
> > > > * component currently using the validator
> > > > * @return The behavior, which can be used for rendering e.g.
> > > > */
> > > > IBehavior getValidationBehavior(Component component);
> > > > }
> > > >
> > > > same here, instanceof check and ready. Not extra code as how to
> > > > interpret it, and all the flexibility that behaviors provide.
> > > >
> > > > Eelco
> > > >
> > >
> >
>
Re: Hibernate Validator integration?
Posted by Ryan Sonnek <ry...@gmail.com>.
I'm a little confused on how these changes would impact the hibernate
integration. anyone care to spell out how this changes the code?
On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
> Sounds good to me.
>
> Eelco
>
> On 5/9/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > what about making iformvalidator extend ivalidator. and ibehaviorprovider
> > extend ivalidator.
> >
> > in formvalidator validatable.value can be form.modelobject() and
> > validatable.error reports an error on form.
> >
> > -igor
> >
> >
> > On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > >
> > > > no. dont forget that the idea of IValidator is to be decoupled from
> > > wicket,
> > > > to allow the reuse of validators in service layer. i do that all the
> > > time
> > > > now and it rocks! my service layer and my ui layer are validated by the
> > > same
> > > > code. adding ivalidator.getbehavior() will break all that nice
> > > decoupling.
> > > >
> > > > i always thought that something like this would work
> > > >
> > > > IClientSideValidator extends IValidator { /** rerturn a js func to
> > > validate
> > > > the value */ CharSequence getValidationScript(); }
> > >
> > > /**
> > > * Validator that provides a behavior, e.g. for rendering client-side or
> > > ajax
> > > * validation. This interface can be implemented by either
> > > * {@link IValidator validators} or {@link IFormValidator form validators}.
> > > */
> > > public interface IBehaviorProvider extends IClusterable
> > > {
> > > /**
> > > * Gets behavior for validation.
> > > *
> > > * @param component
> > > * component currently using the validator
> > > * @return The behavior, which can be used for rendering e.g.
> > > */
> > > IBehavior getValidationBehavior(Component component);
> > > }
> > >
> > > same here, instanceof check and ready. Not extra code as how to
> > > interpret it, and all the flexibility that behaviors provide.
> > >
> > > Eelco
> > >
> >
>
Re: Hibernate Validator integration?
Posted by Eelco Hillenius <ee...@gmail.com>.
Sounds good to me.
Eelco
On 5/9/07, Igor Vaynberg <ig...@gmail.com> wrote:
> what about making iformvalidator extend ivalidator. and ibehaviorprovider
> extend ivalidator.
>
> in formvalidator validatable.value can be form.modelobject() and
> validatable.error reports an error on form.
>
> -igor
>
>
> On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > > no. dont forget that the idea of IValidator is to be decoupled from
> > wicket,
> > > to allow the reuse of validators in service layer. i do that all the
> > time
> > > now and it rocks! my service layer and my ui layer are validated by the
> > same
> > > code. adding ivalidator.getbehavior() will break all that nice
> > decoupling.
> > >
> > > i always thought that something like this would work
> > >
> > > IClientSideValidator extends IValidator { /** rerturn a js func to
> > validate
> > > the value */ CharSequence getValidationScript(); }
> >
> > /**
> > * Validator that provides a behavior, e.g. for rendering client-side or
> > ajax
> > * validation. This interface can be implemented by either
> > * {@link IValidator validators} or {@link IFormValidator form validators}.
> > */
> > public interface IBehaviorProvider extends IClusterable
> > {
> > /**
> > * Gets behavior for validation.
> > *
> > * @param component
> > * component currently using the validator
> > * @return The behavior, which can be used for rendering e.g.
> > */
> > IBehavior getValidationBehavior(Component component);
> > }
> >
> > same here, instanceof check and ready. Not extra code as how to
> > interpret it, and all the flexibility that behaviors provide.
> >
> > Eelco
> >
>
Re: Hibernate Validator integration?
Posted by Eelco Hillenius <ee...@gmail.com>.
Yeah, like I said we can consider that. I'm not sure at this point
though. What I like about this first pass is that it is simple and it
plays through all the rules normal behaviors go through (including
acceptance etc). If we ever allow removing validators, that could be
supported by keeping a set to the behaviors added by the validators
(meaning more state, I know, but it's possible).
Eelco
> don't know if that is really needed
> then that method is easier because else we also have to search for the
> behavior of the validator.
>
> johan
>
>
> On 5/10/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > I just committed the first pass without what you proposed yet. Maybe
> > you can take a look at that Igor?
> >
> > I kept the mechanism as simple as I could. At a later stage, we can
> > see whether we need to optimize (e.g. by not keeping references to the
> > behaviors) though the simplicity of this solution has something going
> > for it as well.
> >
> > Eelco
> >
> > On 5/9/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > what about making iformvalidator extend ivalidator. and
> > ibehaviorprovider
> > > extend ivalidator.
> > >
> > > in formvalidator validatable.value can be form.modelobject() and
> > > validatable.error reports an error on form.
> > >
> > > -igor
> > >
> > >
> > > On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > >
> > > > > no. dont forget that the idea of IValidator is to be decoupled from
> > > > wicket,
> > > > > to allow the reuse of validators in service layer. i do that all the
> > > > time
> > > > > now and it rocks! my service layer and my ui layer are validated by
> > the
> > > > same
> > > > > code. adding ivalidator.getbehavior() will break all that nice
> > > > decoupling.
> > > > >
> > > > > i always thought that something like this would work
> > > > >
> > > > > IClientSideValidator extends IValidator { /** rerturn a js func to
> > > > validate
> > > > > the value */ CharSequence getValidationScript(); }
> > > >
> > > > /**
> > > > * Validator that provides a behavior, e.g. for rendering client-side
> > or
> > > > ajax
> > > > * validation. This interface can be implemented by either
> > > > * {@link IValidator validators} or {@link IFormValidator form
> > validators}.
> > > > */
> > > > public interface IBehaviorProvider extends IClusterable
> > > > {
> > > > /**
> > > > * Gets behavior for validation.
> > > > *
> > > > * @param component
> > > > * component currently using the validator
> > > > * @return The behavior, which can be used for rendering e.g.
> > > > */
> > > > IBehavior getValidationBehavior(Component component);
> > > > }
> > > >
> > > > same here, instanceof check and ready. Not extra code as how to
> > > > interpret it, and all the flexibility that behaviors provide.
> > > >
> > > > Eelco
> > > >
> > >
> >
>
Re: Hibernate Validator integration?
Posted by Johan Compagner <jc...@gmail.com>.
didn't you want to look for validator behaviors at render time?
That has his plusses..
Also when we make a method removeValidator (inline with removeBehavior) but
don't know if that is really needed
then that method is easier because else we also have to search for the
behavior of the validator.
johan
On 5/10/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> I just committed the first pass without what you proposed yet. Maybe
> you can take a look at that Igor?
>
> I kept the mechanism as simple as I could. At a later stage, we can
> see whether we need to optimize (e.g. by not keeping references to the
> behaviors) though the simplicity of this solution has something going
> for it as well.
>
> Eelco
>
> On 5/9/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > what about making iformvalidator extend ivalidator. and
> ibehaviorprovider
> > extend ivalidator.
> >
> > in formvalidator validatable.value can be form.modelobject() and
> > validatable.error reports an error on form.
> >
> > -igor
> >
> >
> > On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > >
> > > > no. dont forget that the idea of IValidator is to be decoupled from
> > > wicket,
> > > > to allow the reuse of validators in service layer. i do that all the
> > > time
> > > > now and it rocks! my service layer and my ui layer are validated by
> the
> > > same
> > > > code. adding ivalidator.getbehavior() will break all that nice
> > > decoupling.
> > > >
> > > > i always thought that something like this would work
> > > >
> > > > IClientSideValidator extends IValidator { /** rerturn a js func to
> > > validate
> > > > the value */ CharSequence getValidationScript(); }
> > >
> > > /**
> > > * Validator that provides a behavior, e.g. for rendering client-side
> or
> > > ajax
> > > * validation. This interface can be implemented by either
> > > * {@link IValidator validators} or {@link IFormValidator form
> validators}.
> > > */
> > > public interface IBehaviorProvider extends IClusterable
> > > {
> > > /**
> > > * Gets behavior for validation.
> > > *
> > > * @param component
> > > * component currently using the validator
> > > * @return The behavior, which can be used for rendering e.g.
> > > */
> > > IBehavior getValidationBehavior(Component component);
> > > }
> > >
> > > same here, instanceof check and ready. Not extra code as how to
> > > interpret it, and all the flexibility that behaviors provide.
> > >
> > > Eelco
> > >
> >
>
Re: Hibernate Validator integration?
Posted by Eelco Hillenius <ee...@gmail.com>.
Ah, yeah. *That's* why it didn't override IClusterable; I was already
wondering that. Sorry for breaking; I'll keep it in mind from now on
(maybe an extra comment wouldn't hurt).
Eelco
On 5/10/07, Igor Vaynberg <ig...@gmail.com> wrote:
> i changed ivalidator extends iclusterable to extends serializable, that way
> we do not break decoupling. if it needs an extra line in terracotta config
> then so be it.
>
> -igor
>
>
> On 5/10/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > I just committed the first pass without what you proposed yet. Maybe
> > you can take a look at that Igor?
> >
> > I kept the mechanism as simple as I could. At a later stage, we can
> > see whether we need to optimize (e.g. by not keeping references to the
> > behaviors) though the simplicity of this solution has something going
> > for it as well.
> >
> > Eelco
> >
> > On 5/9/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > what about making iformvalidator extend ivalidator. and
> > ibehaviorprovider
> > > extend ivalidator.
> > >
> > > in formvalidator validatable.value can be form.modelobject() and
> > > validatable.error reports an error on form.
> > >
> > > -igor
> > >
> > >
> > > On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > >
> > > > > no. dont forget that the idea of IValidator is to be decoupled from
> > > > wicket,
> > > > > to allow the reuse of validators in service layer. i do that all the
> > > > time
> > > > > now and it rocks! my service layer and my ui layer are validated by
> > the
> > > > same
> > > > > code. adding ivalidator.getbehavior() will break all that nice
> > > > decoupling.
> > > > >
> > > > > i always thought that something like this would work
> > > > >
> > > > > IClientSideValidator extends IValidator { /** rerturn a js func to
> > > > validate
> > > > > the value */ CharSequence getValidationScript(); }
> > > >
> > > > /**
> > > > * Validator that provides a behavior, e.g. for rendering client-side
> > or
> > > > ajax
> > > > * validation. This interface can be implemented by either
> > > > * {@link IValidator validators} or {@link IFormValidator form
> > validators}.
> > > > */
> > > > public interface IBehaviorProvider extends IClusterable
> > > > {
> > > > /**
> > > > * Gets behavior for validation.
> > > > *
> > > > * @param component
> > > > * component currently using the validator
> > > > * @return The behavior, which can be used for rendering e.g.
> > > > */
> > > > IBehavior getValidationBehavior(Component component);
> > > > }
> > > >
> > > > same here, instanceof check and ready. Not extra code as how to
> > > > interpret it, and all the flexibility that behaviors provide.
> > > >
> > > > Eelco
> > > >
> > >
> >
>
Re: Hibernate Validator integration?
Posted by Igor Vaynberg <ig...@gmail.com>.
i changed ivalidator extends iclusterable to extends serializable, that way
we do not break decoupling. if it needs an extra line in terracotta config
then so be it.
-igor
On 5/10/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> I just committed the first pass without what you proposed yet. Maybe
> you can take a look at that Igor?
>
> I kept the mechanism as simple as I could. At a later stage, we can
> see whether we need to optimize (e.g. by not keeping references to the
> behaviors) though the simplicity of this solution has something going
> for it as well.
>
> Eelco
>
> On 5/9/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > what about making iformvalidator extend ivalidator. and
> ibehaviorprovider
> > extend ivalidator.
> >
> > in formvalidator validatable.value can be form.modelobject() and
> > validatable.error reports an error on form.
> >
> > -igor
> >
> >
> > On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > >
> > > > no. dont forget that the idea of IValidator is to be decoupled from
> > > wicket,
> > > > to allow the reuse of validators in service layer. i do that all the
> > > time
> > > > now and it rocks! my service layer and my ui layer are validated by
> the
> > > same
> > > > code. adding ivalidator.getbehavior() will break all that nice
> > > decoupling.
> > > >
> > > > i always thought that something like this would work
> > > >
> > > > IClientSideValidator extends IValidator { /** rerturn a js func to
> > > validate
> > > > the value */ CharSequence getValidationScript(); }
> > >
> > > /**
> > > * Validator that provides a behavior, e.g. for rendering client-side
> or
> > > ajax
> > > * validation. This interface can be implemented by either
> > > * {@link IValidator validators} or {@link IFormValidator form
> validators}.
> > > */
> > > public interface IBehaviorProvider extends IClusterable
> > > {
> > > /**
> > > * Gets behavior for validation.
> > > *
> > > * @param component
> > > * component currently using the validator
> > > * @return The behavior, which can be used for rendering e.g.
> > > */
> > > IBehavior getValidationBehavior(Component component);
> > > }
> > >
> > > same here, instanceof check and ready. Not extra code as how to
> > > interpret it, and all the flexibility that behaviors provide.
> > >
> > > Eelco
> > >
> >
>
Re: Hibernate Validator integration?
Posted by Eelco Hillenius <ee...@gmail.com>.
I just committed the first pass without what you proposed yet. Maybe
you can take a look at that Igor?
I kept the mechanism as simple as I could. At a later stage, we can
see whether we need to optimize (e.g. by not keeping references to the
behaviors) though the simplicity of this solution has something going
for it as well.
Eelco
On 5/9/07, Igor Vaynberg <ig...@gmail.com> wrote:
> what about making iformvalidator extend ivalidator. and ibehaviorprovider
> extend ivalidator.
>
> in formvalidator validatable.value can be form.modelobject() and
> validatable.error reports an error on form.
>
> -igor
>
>
> On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > > no. dont forget that the idea of IValidator is to be decoupled from
> > wicket,
> > > to allow the reuse of validators in service layer. i do that all the
> > time
> > > now and it rocks! my service layer and my ui layer are validated by the
> > same
> > > code. adding ivalidator.getbehavior() will break all that nice
> > decoupling.
> > >
> > > i always thought that something like this would work
> > >
> > > IClientSideValidator extends IValidator { /** rerturn a js func to
> > validate
> > > the value */ CharSequence getValidationScript(); }
> >
> > /**
> > * Validator that provides a behavior, e.g. for rendering client-side or
> > ajax
> > * validation. This interface can be implemented by either
> > * {@link IValidator validators} or {@link IFormValidator form validators}.
> > */
> > public interface IBehaviorProvider extends IClusterable
> > {
> > /**
> > * Gets behavior for validation.
> > *
> > * @param component
> > * component currently using the validator
> > * @return The behavior, which can be used for rendering e.g.
> > */
> > IBehavior getValidationBehavior(Component component);
> > }
> >
> > same here, instanceof check and ready. Not extra code as how to
> > interpret it, and all the flexibility that behaviors provide.
> >
> > Eelco
> >
>
Re: Hibernate Validator integration?
Posted by Igor Vaynberg <ig...@gmail.com>.
what about making iformvalidator extend ivalidator. and ibehaviorprovider
extend ivalidator.
in formvalidator validatable.value can be form.modelobject() and
validatable.error reports an error on form.
-igor
On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> > no. dont forget that the idea of IValidator is to be decoupled from
> wicket,
> > to allow the reuse of validators in service layer. i do that all the
> time
> > now and it rocks! my service layer and my ui layer are validated by the
> same
> > code. adding ivalidator.getbehavior() will break all that nice
> decoupling.
> >
> > i always thought that something like this would work
> >
> > IClientSideValidator extends IValidator { /** rerturn a js func to
> validate
> > the value */ CharSequence getValidationScript(); }
>
> /**
> * Validator that provides a behavior, e.g. for rendering client-side or
> ajax
> * validation. This interface can be implemented by either
> * {@link IValidator validators} or {@link IFormValidator form validators}.
> */
> public interface IBehaviorProvider extends IClusterable
> {
> /**
> * Gets behavior for validation.
> *
> * @param component
> * component currently using the validator
> * @return The behavior, which can be used for rendering e.g.
> */
> IBehavior getValidationBehavior(Component component);
> }
>
> same here, instanceof check and ready. Not extra code as how to
> interpret it, and all the flexibility that behaviors provide.
>
> Eelco
>
Re: Hibernate Validator integration?
Posted by Eelco Hillenius <ee...@gmail.com>.
> no. dont forget that the idea of IValidator is to be decoupled from wicket,
> to allow the reuse of validators in service layer. i do that all the time
> now and it rocks! my service layer and my ui layer are validated by the same
> code. adding ivalidator.getbehavior() will break all that nice decoupling.
>
> i always thought that something like this would work
>
> IClientSideValidator extends IValidator { /** rerturn a js func to validate
> the value */ CharSequence getValidationScript(); }
/**
* Validator that provides a behavior, e.g. for rendering client-side or ajax
* validation. This interface can be implemented by either
* {@link IValidator validators} or {@link IFormValidator form validators}.
*/
public interface IBehaviorProvider extends IClusterable
{
/**
* Gets behavior for validation.
*
* @param component
* component currently using the validator
* @return The behavior, which can be used for rendering e.g.
*/
IBehavior getValidationBehavior(Component component);
}
same here, instanceof check and ready. Not extra code as how to
interpret it, and all the flexibility that behaviors provide.
Eelco
Re: Hibernate Validator integration?
Posted by Igor Vaynberg <ig...@gmail.com>.
no. dont forget that the idea of IValidator is to be decoupled from wicket,
to allow the reuse of validators in service layer. i do that all the time
now and it rocks! my service layer and my ui layer are validated by the same
code. adding ivalidator.getbehavior() will break all that nice decoupling.
i always thought that something like this would work
IClientSideValidator extends IValidator { /** rerturn a js func to validate
the value */ CharSequence getValidationScript(); }
then an instanceof check and you are done.
-igor
On 5/9/07, Johan Compagner <jc...@gmail.com> wrote:
>
> a problem is that IBehavior is a pretty big interface
> And you work from the validator so its a lot of garbage a validator will
> get
> when it also implements IBehavior
> and we don't have multiply inheritance in java so it will be very hard to
> reuse stuff then
>
> That only is possible if we have this:
>
> IValidator.getBehavior()
>
> then the validator returns the behavior it also wants to have.
> then when add(IValidator) is called we check if it has a behavior (or its
> a
> IClientValidator or IValidatorBehavior whatever)
> and if it has one we call add(IBehavior) with that one automatically
>
> This way current validators can be come client side validators very easily
> and one behavior can be reused multiply times that would be much harder
> if
> it really was one big class.
>
> johan
>
>
>
>
> On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > I'm not sure. It's smart to use a behavior for this, as that's very
> > flexible and enables you to add client-side things (by adding other
> > behaviors) easily.
> >
> > I'm not crazy about a behavior changing properties of components. It's
> > not wrong, but I think I'd prefer to let the component as is and make
> > a smart validator that just works on itself.
> >
> > I also think that the solution is a bit hackish. It's great to make
> > things work quickly, but in this case I'd rather see whether we can
> > find something generic, even if that would mean alterations in
> > Wicket's (internal) API as well.
> >
> > To do that, we have a couple of things to tackle:
> >
> > 1) Validators are currently server side all-the-way. But they don't
> > have to be imho. If you combine a behavior and validator, you can
> > create a validator that checks on the server side (imo, *always* do
> > that, even if you have the client side covered well) and additionally
> > write out some client side validation script. I see two ways to
> > achieve this:
> > a) Really make a combined class, but then we should extract a
> > combined interface for IValidator and IBehavior, so that you can add
> > such a class to a component with just one method call
> > b) Introduce a limited IBehavior-like interface that can be extended
> > by IValidators and that is to be interpreted when rendering by form
> > components.
> > My very strong preference is a), as I think it would be nice to be
> > able to do that anyway. The only people we'd break are the people who
> > override add(Behavior) now - something that we've warned against to
> > start with - but we can find another way to support their use case.
> >
> > 2) We should refine our concept of property models. It's still a
> > special case right now, though when you think of it, it's really a
> > very generic problem to solve, whether introspection is used or not.
> > PropertyModels need to know the following things:
> > * The parent type of the property (e.g. Person). One tricky thing
> > here is nested properties (like 'person.homeAddress.postalCode'), but
> > I'm sure we can find some solution.
> > * The type of the property ('name' is a string, 'dateOfBirth' a date).
> > * The property name. Probably usually equal to the property
> > expression if one is available.
> >
> > In short, 1) would provide a means to let validators optionally
> > contribute client side code while still having a solid server-side
> > shield, and 2) provides all the means needed for introspecting on the
> > kind of validation that should be executed.
> >
> > WDYT?
> >
> > Eelco
> >
> >
> > On 5/9/07, Ryan Sonnek <ry...@gmail.com> wrote:
> > > Wow. After a flurry of research into this area, i've whipped together
> > > a hibernate/wicket behavior that reads annotations and helps configure
> > > the wicket component respectively.
> > >
> >
> http://wicket-stuff.svn.sourceforge.net/viewvc/wicket-stuff/trunk/wicketstuff-hibernate-behavior/
> > >
> > > Essentially, right now it will auto configure a component by:
> > > * set component to be "required" when using NotNull annotation
> > > * add "maxlength" attribute when using Length annotation
> > >
> > > Still lots of work to be done:
> > > * attach client side javascript validation
> > > * maybe integrate into the wicket validation framework?
> > >
> > > I'd appreciate anyone interested to take a look and let me know what
> > they think.
> > >
> > > On 5/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > > > Ryan, lets finish this thread and move on to gTalk and *talk*
> about
> > this.
> > > > > I'm adding you right now.
> > > >
> > > > Or even better... why don't you guys join the ##wicket IRC channel
> on
> > > > freenode.net? It's perfect for discussions like that, and changes
> are
> > > > you'll get some more people opinions in the process (44 people
> hanging
> > > > out as I write this).
> > > >
> > > > > No, I dont have an account yet, and yes you can start the project
> in
> > > > > wicket-stuff and after that, I'll ask you for permission. What'd
> you
> > think?
> > > >
> > > > Please reply with (or send me) your sourceforge id, and I'll be
> happy
> > > > to add you to wicket-stuff.
> > > >
> > > > Eelco
> > > >
> > >
> >
>
Re: Hibernate Validator integration?
Posted by Johan Compagner <jc...@gmail.com>.
And if you implement AbstractBehavior you can't reuse all the current
validators
you have to copy paste or rewrite them
If you do it the other way you have to copy paste the behavior code..
both ways its a big ugly if you ask me
johan
On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > a problem is that IBehavior is a pretty big interface
> > > And you work from the validator so its a lot of garbage a validator
> will get
> > > when it also implements IBehavior
> > > and we don't have multiply inheritance in java so it will be very hard
> to
> > > reuse stuff then
> > >
> > > That only is possible if we have this:
> > >
> > > IValidator.getBehavior()
> > >
> > > then the validator returns the behavior it also wants to have.
> > > then when add(IValidator) is called we check if it has a behavior (or
> its a
> > > IClientValidator or IValidatorBehavior whatever)
> > > and if it has one we call add(IBehavior) with that one automatically
> > >
> > > This way current validators can be come client side validators very
> easily
> > > and one behavior can be reused multiply times that would be much
> harder if
> > > it really was one big class.
> >
> > Good point. I'll see if I can implement this when I'm on the train to
> Deventer.
> >
> > Eelco
> >
>
> Though I'm not yet completely convinced, as a class that extends
> AbstractBehavior and implements IValidator isn't much bloat from a
> user's perspective... more later.
>
> Eelco
>
Re: Hibernate Validator integration?
Posted by Johan Compagner <jc...@gmail.com>.
i have now an validator
and i attach to that validator also client side behavior
then i think hmm i want now to do this with ajax
then i just attach another behavior to that validator that does a ajax call
to the validator itself..
so it gives you a bit more freedom.
johan
On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > a problem is that IBehavior is a pretty big interface
> > > And you work from the validator so its a lot of garbage a validator
> will get
> > > when it also implements IBehavior
> > > and we don't have multiply inheritance in java so it will be very hard
> to
> > > reuse stuff then
> > >
> > > That only is possible if we have this:
> > >
> > > IValidator.getBehavior()
> > >
> > > then the validator returns the behavior it also wants to have.
> > > then when add(IValidator) is called we check if it has a behavior (or
> its a
> > > IClientValidator or IValidatorBehavior whatever)
> > > and if it has one we call add(IBehavior) with that one automatically
> > >
> > > This way current validators can be come client side validators very
> easily
> > > and one behavior can be reused multiply times that would be much
> harder if
> > > it really was one big class.
> >
> > Good point. I'll see if I can implement this when I'm on the train to
> Deventer.
> >
> > Eelco
> >
>
> Though I'm not yet completely convinced, as a class that extends
> AbstractBehavior and implements IValidator isn't much bloat from a
> user's perspective... more later.
>
> Eelco
>
Re: Hibernate Validator integration?
Posted by Eelco Hillenius <ee...@gmail.com>.
On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > a problem is that IBehavior is a pretty big interface
> > And you work from the validator so its a lot of garbage a validator will get
> > when it also implements IBehavior
> > and we don't have multiply inheritance in java so it will be very hard to
> > reuse stuff then
> >
> > That only is possible if we have this:
> >
> > IValidator.getBehavior()
> >
> > then the validator returns the behavior it also wants to have.
> > then when add(IValidator) is called we check if it has a behavior (or its a
> > IClientValidator or IValidatorBehavior whatever)
> > and if it has one we call add(IBehavior) with that one automatically
> >
> > This way current validators can be come client side validators very easily
> > and one behavior can be reused multiply times that would be much harder if
> > it really was one big class.
>
> Good point. I'll see if I can implement this when I'm on the train to Deventer.
>
> Eelco
>
Though I'm not yet completely convinced, as a class that extends
AbstractBehavior and implements IValidator isn't much bloat from a
user's perspective... more later.
Eelco
Re: Hibernate Validator integration?
Posted by Eelco Hillenius <ee...@gmail.com>.
> a problem is that IBehavior is a pretty big interface
> And you work from the validator so its a lot of garbage a validator will get
> when it also implements IBehavior
> and we don't have multiply inheritance in java so it will be very hard to
> reuse stuff then
>
> That only is possible if we have this:
>
> IValidator.getBehavior()
>
> then the validator returns the behavior it also wants to have.
> then when add(IValidator) is called we check if it has a behavior (or its a
> IClientValidator or IValidatorBehavior whatever)
> and if it has one we call add(IBehavior) with that one automatically
>
> This way current validators can be come client side validators very easily
> and one behavior can be reused multiply times that would be much harder if
> it really was one big class.
Good point. I'll see if I can implement this when I'm on the train to Deventer.
Eelco
Re: Hibernate Validator integration?
Posted by Johan Compagner <jc...@gmail.com>.
a problem is that IBehavior is a pretty big interface
And you work from the validator so its a lot of garbage a validator will get
when it also implements IBehavior
and we don't have multiply inheritance in java so it will be very hard to
reuse stuff then
That only is possible if we have this:
IValidator.getBehavior()
then the validator returns the behavior it also wants to have.
then when add(IValidator) is called we check if it has a behavior (or its a
IClientValidator or IValidatorBehavior whatever)
and if it has one we call add(IBehavior) with that one automatically
This way current validators can be come client side validators very easily
and one behavior can be reused multiply times that would be much harder if
it really was one big class.
johan
On 5/9/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> I'm not sure. It's smart to use a behavior for this, as that's very
> flexible and enables you to add client-side things (by adding other
> behaviors) easily.
>
> I'm not crazy about a behavior changing properties of components. It's
> not wrong, but I think I'd prefer to let the component as is and make
> a smart validator that just works on itself.
>
> I also think that the solution is a bit hackish. It's great to make
> things work quickly, but in this case I'd rather see whether we can
> find something generic, even if that would mean alterations in
> Wicket's (internal) API as well.
>
> To do that, we have a couple of things to tackle:
>
> 1) Validators are currently server side all-the-way. But they don't
> have to be imho. If you combine a behavior and validator, you can
> create a validator that checks on the server side (imo, *always* do
> that, even if you have the client side covered well) and additionally
> write out some client side validation script. I see two ways to
> achieve this:
> a) Really make a combined class, but then we should extract a
> combined interface for IValidator and IBehavior, so that you can add
> such a class to a component with just one method call
> b) Introduce a limited IBehavior-like interface that can be extended
> by IValidators and that is to be interpreted when rendering by form
> components.
> My very strong preference is a), as I think it would be nice to be
> able to do that anyway. The only people we'd break are the people who
> override add(Behavior) now - something that we've warned against to
> start with - but we can find another way to support their use case.
>
> 2) We should refine our concept of property models. It's still a
> special case right now, though when you think of it, it's really a
> very generic problem to solve, whether introspection is used or not.
> PropertyModels need to know the following things:
> * The parent type of the property (e.g. Person). One tricky thing
> here is nested properties (like 'person.homeAddress.postalCode'), but
> I'm sure we can find some solution.
> * The type of the property ('name' is a string, 'dateOfBirth' a date).
> * The property name. Probably usually equal to the property
> expression if one is available.
>
> In short, 1) would provide a means to let validators optionally
> contribute client side code while still having a solid server-side
> shield, and 2) provides all the means needed for introspecting on the
> kind of validation that should be executed.
>
> WDYT?
>
> Eelco
>
>
> On 5/9/07, Ryan Sonnek <ry...@gmail.com> wrote:
> > Wow. After a flurry of research into this area, i've whipped together
> > a hibernate/wicket behavior that reads annotations and helps configure
> > the wicket component respectively.
> >
> http://wicket-stuff.svn.sourceforge.net/viewvc/wicket-stuff/trunk/wicketstuff-hibernate-behavior/
> >
> > Essentially, right now it will auto configure a component by:
> > * set component to be "required" when using NotNull annotation
> > * add "maxlength" attribute when using Length annotation
> >
> > Still lots of work to be done:
> > * attach client side javascript validation
> > * maybe integrate into the wicket validation framework?
> >
> > I'd appreciate anyone interested to take a look and let me know what
> they think.
> >
> > On 5/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > > Ryan, lets finish this thread and move on to gTalk and *talk* about
> this.
> > > > I'm adding you right now.
> > >
> > > Or even better... why don't you guys join the ##wicket IRC channel on
> > > freenode.net? It's perfect for discussions like that, and changes are
> > > you'll get some more people opinions in the process (44 people hanging
> > > out as I write this).
> > >
> > > > No, I dont have an account yet, and yes you can start the project in
> > > > wicket-stuff and after that, I'll ask you for permission. What'd you
> think?
> > >
> > > Please reply with (or send me) your sourceforge id, and I'll be happy
> > > to add you to wicket-stuff.
> > >
> > > Eelco
> > >
> >
>
Re: Hibernate Validator integration?
Posted by Ryan Sonnek <ry...@gmail.com>.
> I also think that the solution is a bit hackish. It's great to make
> things work quickly, but in this case I'd rather see whether we can
> find something generic, even if that would mean alterations in
> Wicket's (internal) API as well.
A *bit* hackish? =) I'd say a *lot* hackish right now. I just
wanted to get this out the door because
A. It "works"
B. to try and get some direction on where this kind of project should go.
Thanks for the initial feedback, and I hope to hear more about where
to take this.
Re: Hibernate Validator integration?
Posted by Eelco Hillenius <ee...@gmail.com>.
I'm not sure. It's smart to use a behavior for this, as that's very
flexible and enables you to add client-side things (by adding other
behaviors) easily.
I'm not crazy about a behavior changing properties of components. It's
not wrong, but I think I'd prefer to let the component as is and make
a smart validator that just works on itself.
I also think that the solution is a bit hackish. It's great to make
things work quickly, but in this case I'd rather see whether we can
find something generic, even if that would mean alterations in
Wicket's (internal) API as well.
To do that, we have a couple of things to tackle:
1) Validators are currently server side all-the-way. But they don't
have to be imho. If you combine a behavior and validator, you can
create a validator that checks on the server side (imo, *always* do
that, even if you have the client side covered well) and additionally
write out some client side validation script. I see two ways to
achieve this:
a) Really make a combined class, but then we should extract a
combined interface for IValidator and IBehavior, so that you can add
such a class to a component with just one method call
b) Introduce a limited IBehavior-like interface that can be extended
by IValidators and that is to be interpreted when rendering by form
components.
My very strong preference is a), as I think it would be nice to be
able to do that anyway. The only people we'd break are the people who
override add(Behavior) now - something that we've warned against to
start with - but we can find another way to support their use case.
2) We should refine our concept of property models. It's still a
special case right now, though when you think of it, it's really a
very generic problem to solve, whether introspection is used or not.
PropertyModels need to know the following things:
* The parent type of the property (e.g. Person). One tricky thing
here is nested properties (like 'person.homeAddress.postalCode'), but
I'm sure we can find some solution.
* The type of the property ('name' is a string, 'dateOfBirth' a date).
* The property name. Probably usually equal to the property
expression if one is available.
In short, 1) would provide a means to let validators optionally
contribute client side code while still having a solid server-side
shield, and 2) provides all the means needed for introspecting on the
kind of validation that should be executed.
WDYT?
Eelco
On 5/9/07, Ryan Sonnek <ry...@gmail.com> wrote:
> Wow. After a flurry of research into this area, i've whipped together
> a hibernate/wicket behavior that reads annotations and helps configure
> the wicket component respectively.
> http://wicket-stuff.svn.sourceforge.net/viewvc/wicket-stuff/trunk/wicketstuff-hibernate-behavior/
>
> Essentially, right now it will auto configure a component by:
> * set component to be "required" when using NotNull annotation
> * add "maxlength" attribute when using Length annotation
>
> Still lots of work to be done:
> * attach client side javascript validation
> * maybe integrate into the wicket validation framework?
>
> I'd appreciate anyone interested to take a look and let me know what they think.
>
> On 5/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > Ryan, lets finish this thread and move on to gTalk and *talk* about this.
> > > I'm adding you right now.
> >
> > Or even better... why don't you guys join the ##wicket IRC channel on
> > freenode.net? It's perfect for discussions like that, and changes are
> > you'll get some more people opinions in the process (44 people hanging
> > out as I write this).
> >
> > > No, I dont have an account yet, and yes you can start the project in
> > > wicket-stuff and after that, I'll ask you for permission. What'd you think?
> >
> > Please reply with (or send me) your sourceforge id, and I'll be happy
> > to add you to wicket-stuff.
> >
> > Eelco
> >
>
Re: Hibernate Validator integration?
Posted by Xavier Hanin <xa...@gmail.com>.
On 5/10/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> Yeah, for sure. Everyone is more than welcome to help with this (and
> I'll only be looking from the side line to see whether we can do more
> in the core project to support this very interesting case further),
> especially when you want to use it for real.
>
> So officially Ryan and Bruno are working on this. Imho (as a lover of
> anarchy) it works great to see a couple of competing implementations
> in the same project so that we can grow to the best solution from
> there. But that's all up to you guys. :)
I'm not sure I'll have time to help much, at least for the moment. But if my
choice about validation goes to hibernate validator, I'll be a good
candidate at least to provide some testing :-)
Xavier
Eelco
>
>
> On 5/10/07, Xavier Hanin <xa...@gmail.com> wrote:
> > On 5/10/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > >
> > > > > Similarly, the Length element can and probably should be using a
> > > > > StringValidator for a TextField and not setting maxlength. Maybe
> it
> > > > > should do both. ;-)
> > > > I've thought about using validators here and "ideally" would use a
> > > > StringValidatorWithBehavior that would automatically attach the
> markup
> > > > attributes. any thoughts?
> > >
> > > Yeah, something like that is now possible:
> > >
> > > private static class MaxLengthValidator extends
> > > StringValidator.MaximumLengthValidator
> > > implements
> > > IBehaviorProvider
> > > {
> > > public MaxLengthValidator(int maximum)
> > > {
> > > super(maximum);
> > > }
> > >
> > > /**
> > > * @see
> > > org.apache.wicket.validation.IBehaviorProvider#newValidationBehavior(
> > > org.apache.wicket.Component)
> > > */
> > > public IBehavior newValidationBehavior(Component
> > > component)
> > > {
> > > if (component instanceof
> AbstractTextComponent)
> > > {
> > > return new
> > > SimpleAttributeModifier("maxlength",
> > > String.valueOf(getMaximum()));
> > > }
> > > return null;
> > > }
> > > }
> > >
> > > The API still is to be reviewed and tweaked, but this is the basic
> idea.
> > >
> > > > > It strikes me we probably need a:
> > > > >
> > > > > Hibernate Validator Attribute + Component type -> Validator
> mapping
> > > > >
> > > > > ...because what sort of validator you want to use will be
> dependent on
> > > > > the component type.
> > > >
> > > > I actually think I would like to create a application component
> > > > listener for this (similar to the SpringBean component listener) so
> > > > that an entire application will "just work" and you don't have to
> > > > worry about manually adding validators at all. thoughts?
> > > > Ryan
> > >
> > > That's an interesting idea; might work out pretty cool. Best thing
> > > again is to create a first pass and see how it works.
> > >
> > > Any plans for creating an example application for this? If you ever
> > > want this to get a good ammount of traction, it needs one.
> >
> >
> > I still have to make further investigation but I think I'd be interested
> in
> > this implementation too. I'm working on an open source project which is
> > still in very early stage, but if we use this Hibernate Validator
> > integration it may be an option to show some part of the app as a real
> live
> > example. The drawback is that real live app is often much more difficult
> to
> > understand in a few minutes than an example app developed only for
> showcase
> > purpose, but I thought you might be interested in this.
> >
> > If you are interested, I'll keep you informed depending on my
> investigation
> > and my progress.
> >
> > Xavier
> >
> > Eelco
> > >
> >
> >
> >
> > --
> > Xavier Hanin - Independent Java Consultant
> > Manage your dependencies with Ivy!
> > http://incubator.apache.org/ivy/
> >
>
--
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/
Re: Hibernate Validator integration?
Posted by Eelco Hillenius <ee...@gmail.com>.
Yeah, for sure. Everyone is more than welcome to help with this (and
I'll only be looking from the side line to see whether we can do more
in the core project to support this very interesting case further),
especially when you want to use it for real.
So officially Ryan and Bruno are working on this. Imho (as a lover of
anarchy) it works great to see a couple of competing implementations
in the same project so that we can grow to the best solution from
there. But that's all up to you guys. :)
Eelco
On 5/10/07, Xavier Hanin <xa...@gmail.com> wrote:
> On 5/10/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > > > Similarly, the Length element can and probably should be using a
> > > > StringValidator for a TextField and not setting maxlength. Maybe it
> > > > should do both. ;-)
> > > I've thought about using validators here and "ideally" would use a
> > > StringValidatorWithBehavior that would automatically attach the markup
> > > attributes. any thoughts?
> >
> > Yeah, something like that is now possible:
> >
> > private static class MaxLengthValidator extends
> > StringValidator.MaximumLengthValidator
> > implements
> > IBehaviorProvider
> > {
> > public MaxLengthValidator(int maximum)
> > {
> > super(maximum);
> > }
> >
> > /**
> > * @see
> > org.apache.wicket.validation.IBehaviorProvider#newValidationBehavior(
> > org.apache.wicket.Component)
> > */
> > public IBehavior newValidationBehavior(Component
> > component)
> > {
> > if (component instanceof AbstractTextComponent)
> > {
> > return new
> > SimpleAttributeModifier("maxlength",
> > String.valueOf(getMaximum()));
> > }
> > return null;
> > }
> > }
> >
> > The API still is to be reviewed and tweaked, but this is the basic idea.
> >
> > > > It strikes me we probably need a:
> > > >
> > > > Hibernate Validator Attribute + Component type -> Validator mapping
> > > >
> > > > ...because what sort of validator you want to use will be dependent on
> > > > the component type.
> > >
> > > I actually think I would like to create a application component
> > > listener for this (similar to the SpringBean component listener) so
> > > that an entire application will "just work" and you don't have to
> > > worry about manually adding validators at all. thoughts?
> > > Ryan
> >
> > That's an interesting idea; might work out pretty cool. Best thing
> > again is to create a first pass and see how it works.
> >
> > Any plans for creating an example application for this? If you ever
> > want this to get a good ammount of traction, it needs one.
>
>
> I still have to make further investigation but I think I'd be interested in
> this implementation too. I'm working on an open source project which is
> still in very early stage, but if we use this Hibernate Validator
> integration it may be an option to show some part of the app as a real live
> example. The drawback is that real live app is often much more difficult to
> understand in a few minutes than an example app developed only for showcase
> purpose, but I thought you might be interested in this.
>
> If you are interested, I'll keep you informed depending on my investigation
> and my progress.
>
> Xavier
>
> Eelco
> >
>
>
>
> --
> Xavier Hanin - Independent Java Consultant
> Manage your dependencies with Ivy!
> http://incubator.apache.org/ivy/
>
Re: Hibernate Validator integration?
Posted by Xavier Hanin <xa...@gmail.com>.
On 5/10/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> > > Similarly, the Length element can and probably should be using a
> > > StringValidator for a TextField and not setting maxlength. Maybe it
> > > should do both. ;-)
> > I've thought about using validators here and "ideally" would use a
> > StringValidatorWithBehavior that would automatically attach the markup
> > attributes. any thoughts?
>
> Yeah, something like that is now possible:
>
> private static class MaxLengthValidator extends
> StringValidator.MaximumLengthValidator
> implements
> IBehaviorProvider
> {
> public MaxLengthValidator(int maximum)
> {
> super(maximum);
> }
>
> /**
> * @see
> org.apache.wicket.validation.IBehaviorProvider#newValidationBehavior(
> org.apache.wicket.Component)
> */
> public IBehavior newValidationBehavior(Component
> component)
> {
> if (component instanceof AbstractTextComponent)
> {
> return new
> SimpleAttributeModifier("maxlength",
> String.valueOf(getMaximum()));
> }
> return null;
> }
> }
>
> The API still is to be reviewed and tweaked, but this is the basic idea.
>
> > > It strikes me we probably need a:
> > >
> > > Hibernate Validator Attribute + Component type -> Validator mapping
> > >
> > > ...because what sort of validator you want to use will be dependent on
> > > the component type.
> >
> > I actually think I would like to create a application component
> > listener for this (similar to the SpringBean component listener) so
> > that an entire application will "just work" and you don't have to
> > worry about manually adding validators at all. thoughts?
> > Ryan
>
> That's an interesting idea; might work out pretty cool. Best thing
> again is to create a first pass and see how it works.
>
> Any plans for creating an example application for this? If you ever
> want this to get a good ammount of traction, it needs one.
I still have to make further investigation but I think I'd be interested in
this implementation too. I'm working on an open source project which is
still in very early stage, but if we use this Hibernate Validator
integration it may be an option to show some part of the app as a real live
example. The drawback is that real live app is often much more difficult to
understand in a few minutes than an example app developed only for showcase
purpose, but I thought you might be interested in this.
If you are interested, I'll keep you informed depending on my investigation
and my progress.
Xavier
Eelco
>
--
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/
Re: Hibernate Validator integration?
Posted by Eelco Hillenius <ee...@gmail.com>.
> > Similarly, the Length element can and probably should be using a
> > StringValidator for a TextField and not setting maxlength. Maybe it
> > should do both. ;-)
> I've thought about using validators here and "ideally" would use a
> StringValidatorWithBehavior that would automatically attach the markup
> attributes. any thoughts?
Yeah, something like that is now possible:
private static class MaxLengthValidator extends
StringValidator.MaximumLengthValidator
implements
IBehaviorProvider
{
public MaxLengthValidator(int maximum)
{
super(maximum);
}
/**
* @see org.apache.wicket.validation.IBehaviorProvider#newValidationBehavior(org.apache.wicket.Component)
*/
public IBehavior newValidationBehavior(Component component)
{
if (component instanceof AbstractTextComponent)
{
return new SimpleAttributeModifier("maxlength",
String.valueOf(getMaximum()));
}
return null;
}
}
The API still is to be reviewed and tweaked, but this is the basic idea.
> > It strikes me we probably need a:
> >
> > Hibernate Validator Attribute + Component type -> Validator mapping
> >
> > ...because what sort of validator you want to use will be dependent on
> > the component type.
>
> I actually think I would like to create a application component
> listener for this (similar to the SpringBean component listener) so
> that an entire application will "just work" and you don't have to
> worry about manually adding validators at all. thoughts?
> Ryan
That's an interesting idea; might work out pretty cool. Best thing
again is to create a first pass and see how it works.
Any plans for creating an example application for this? If you ever
want this to get a good ammount of traction, it needs one.
Eelco
Re: Hibernate Validator integration?
Posted by Ryan Sonnek <ry...@gmail.com>.
On 5/10/07, Al Maw <wi...@almaw.com> wrote:
> Ryan Sonnek wrote:
> > I'd appreciate anyone interested to take a look and let me know what
> > they think.
>
> You currently setRequired(true) on a NotEmpty, which isn't what that
> intends at all.
>
> It's purpose is to make sure a String is length > 0, or a collection has
> more than zero elements.
Might not be correct for collections, but should work for strings right?
> Similarly, the Length element can and probably should be using a
> StringValidator for a TextField and not setting maxlength. Maybe it
> should do both. ;-)
I've thought about using validators here and "ideally" would use a
StringValidatorWithBehavior that would automatically attach the markup
attributes. any thoughts?
>
> It strikes me we probably need a:
>
> Hibernate Validator Attribute + Component type -> Validator mapping
>
> ...because what sort of validator you want to use will be dependent on
> the component type.
>
> Al
>
I actually think I would like to create a application component
listener for this (similar to the SpringBean component listener) so
that an entire application will "just work" and you don't have to
worry about manually adding validators at all. thoughts?
Ryan
Re: Hibernate Validator integration?
Posted by Al Maw <wi...@almaw.com>.
Ryan Sonnek wrote:
> I'd appreciate anyone interested to take a look and let me know what
> they think.
You currently setRequired(true) on a NotEmpty, which isn't what that
intends at all.
It's purpose is to make sure a String is length > 0, or a collection has
more than zero elements.
Similarly, the Length element can and probably should be using a
StringValidator for a TextField and not setting maxlength. Maybe it
should do both. ;-)
It strikes me we probably need a:
Hibernate Validator Attribute + Component type -> Validator mapping
...because what sort of validator you want to use will be dependent on
the component type.
Al
Re: Hibernate Validator integration?
Posted by Ryan Sonnek <ry...@gmail.com>.
AJAX vs client side validation is a really good point. I'll keep this
in mind and try to leverage server side logic as much as possible.
On 5/9/07, Johan Compagner <jc...@gmail.com> wrote:
> also when you look at client side validation look into ajax validation
> currently i don't find client side that big of an issue. because you can use
> your java validation
> rules just fine when you use ajax..
>
> johan
>
>
> On 5/9/07, Ryan Sonnek <ry...@gmail.com> wrote:
> >
> > Wow. After a flurry of research into this area, i've whipped together
> > a hibernate/wicket behavior that reads annotations and helps configure
> > the wicket component respectively.
> >
> > http://wicket-stuff.svn.sourceforge.net/viewvc/wicket-stuff/trunk/wicketstuff-hibernate-behavior/
> >
> > Essentially, right now it will auto configure a component by:
> > * set component to be "required" when using NotNull annotation
> > * add "maxlength" attribute when using Length annotation
> >
> > Still lots of work to be done:
> > * attach client side javascript validation
> > * maybe integrate into the wicket validation framework?
> >
> > I'd appreciate anyone interested to take a look and let me know what they
> > think.
> >
> > On 5/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > > Ryan, lets finish this thread and move on to gTalk and *talk* about
> > this.
> > > > I'm adding you right now.
> > >
> > > Or even better... why don't you guys join the ##wicket IRC channel on
> > > freenode.net? It's perfect for discussions like that, and changes are
> > > you'll get some more people opinions in the process (44 people hanging
> > > out as I write this).
> > >
> > > > No, I dont have an account yet, and yes you can start the project in
> > > > wicket-stuff and after that, I'll ask you for permission. What'd you
> > think?
> > >
> > > Please reply with (or send me) your sourceforge id, and I'll be happy
> > > to add you to wicket-stuff.
> > >
> > > Eelco
> > >
> >
>
Re: Hibernate Validator integration?
Posted by Johan Compagner <jc...@gmail.com>.
also when you look at client side validation look into ajax validation
currently i don't find client side that big of an issue. because you can use
your java validation
rules just fine when you use ajax..
johan
On 5/9/07, Ryan Sonnek <ry...@gmail.com> wrote:
>
> Wow. After a flurry of research into this area, i've whipped together
> a hibernate/wicket behavior that reads annotations and helps configure
> the wicket component respectively.
>
> http://wicket-stuff.svn.sourceforge.net/viewvc/wicket-stuff/trunk/wicketstuff-hibernate-behavior/
>
> Essentially, right now it will auto configure a component by:
> * set component to be "required" when using NotNull annotation
> * add "maxlength" attribute when using Length annotation
>
> Still lots of work to be done:
> * attach client side javascript validation
> * maybe integrate into the wicket validation framework?
>
> I'd appreciate anyone interested to take a look and let me know what they
> think.
>
> On 5/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > Ryan, lets finish this thread and move on to gTalk and *talk* about
> this.
> > > I'm adding you right now.
> >
> > Or even better... why don't you guys join the ##wicket IRC channel on
> > freenode.net? It's perfect for discussions like that, and changes are
> > you'll get some more people opinions in the process (44 people hanging
> > out as I write this).
> >
> > > No, I dont have an account yet, and yes you can start the project in
> > > wicket-stuff and after that, I'll ask you for permission. What'd you
> think?
> >
> > Please reply with (or send me) your sourceforge id, and I'll be happy
> > to add you to wicket-stuff.
> >
> > Eelco
> >
>
Re: Hibernate Validator integration?
Posted by Ryan Sonnek <ry...@gmail.com>.
Wow. After a flurry of research into this area, i've whipped together
a hibernate/wicket behavior that reads annotations and helps configure
the wicket component respectively.
http://wicket-stuff.svn.sourceforge.net/viewvc/wicket-stuff/trunk/wicketstuff-hibernate-behavior/
Essentially, right now it will auto configure a component by:
* set component to be "required" when using NotNull annotation
* add "maxlength" attribute when using Length annotation
Still lots of work to be done:
* attach client side javascript validation
* maybe integrate into the wicket validation framework?
I'd appreciate anyone interested to take a look and let me know what they think.
On 5/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > Ryan, lets finish this thread and move on to gTalk and *talk* about this.
> > I'm adding you right now.
>
> Or even better... why don't you guys join the ##wicket IRC channel on
> freenode.net? It's perfect for discussions like that, and changes are
> you'll get some more people opinions in the process (44 people hanging
> out as I write this).
>
> > No, I dont have an account yet, and yes you can start the project in
> > wicket-stuff and after that, I'll ask you for permission. What'd you think?
>
> Please reply with (or send me) your sourceforge id, and I'll be happy
> to add you to wicket-stuff.
>
> Eelco
>
Re: Hibernate Validator integration?
Posted by Eelco Hillenius <ee...@gmail.com>.
> Ryan, lets finish this thread and move on to gTalk and *talk* about this.
> I'm adding you right now.
Or even better... why don't you guys join the ##wicket IRC channel on
freenode.net? It's perfect for discussions like that, and changes are
you'll get some more people opinions in the process (44 people hanging
out as I write this).
> No, I dont have an account yet, and yes you can start the project in
> wicket-stuff and after that, I'll ask you for permission. What'd you think?
Please reply with (or send me) your sourceforge id, and I'll be happy
to add you to wicket-stuff.
Eelco
Re: Hibernate Validator integration?
Posted by Bruno Borges <br...@gmail.com>.
Ryan, lets finish this thread and move on to gTalk and *talk* about this.
I'm adding you right now.
No, I dont have an account yet, and yes you can start the project in
wicket-stuff and after that, I'll ask you for permission. What'd you think?
[]' s
--
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(48) 8404-1300
(11) 3055-2060
On 5/8/07, Ryan Sonnek <ry...@gmail.com> wrote:
>
> Hey Bruno, I'd love to contribute. My experience with annotations and
> hibernate validators is very limited, but I'd love to dig in. do you
> have any place to start for source code? I'd like to start a small
> project in wicket-stuff to try this out. do you have account setup
> for wicket-stuff access?
>
> On 5/8/07, Bruno Borges <br...@gmail.com> wrote:
> > Ryan, want to work together on this?
> >
> > Regards,
> > --
> > Bruno Borges
> > Summa Technologies Inc.
> > www.summa-tech.com
> > (48) 8404-1300
> > (11) 3055-2060
> >
> > On 5/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > >
> > > I think someone (you?) just has to take up the initiative. I think the
> > > core team is too tight up atm.
> > >
> > > Eelco
> > >
> > >
> > > On 5/8/07, Ryan Sonnek <ry...@gmail.com> wrote:
> > > > I haven't heard anything on this thread for a while, and it seemed
> > > > really exciting. Has there been any progress on creating a wicket
> > > > validator that uses hibernate annotations? anything available in
> > > > wicket-stuff to take a look at?
> > > >
> > > > On 4/25/07, Xavier Hanin <xa...@gmail.com> wrote:
> > > > > On 4/25/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > > > naah, we share this list with wicket-stuff. makes it easier.
> > > > > Ok, sorry, next time I'll just put a +1 to give my opinion, it
> will
> > > > > save a couple of emails :-)
> > > > >
> > > > > Xavier
> > > > >
> > > > > >
> > > > > > -igor
> > > > > >
> > > > > >
> > > > > > On 4/25/07, Xavier Hanin <xa...@gmail.com> wrote:
> > > > > > >
> > > > > > > On 4/25/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > > > > > why would our opinion matter? you are free to start a
> > > wicket-stuff
> > > > > > > project
> > > > > > > > to integrate whatever you want :)
> > > > > > > Agreed, but since Bruno posted on the dev mailing list, I
> thought
> > > he
> > > > > > > was more specifically asking opinion from the wicket team.
> > > > > > >
> > > > > > > Xavier
> > > > > > >
> > > > > > > >
> > > > > > > > -igor
> > > > > > > >
> > > > > > > >
> > > > > > > > On 4/25/07, Xavier Hanin <xa...@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > On 4/25/07, Bruno Borges <br...@gmail.com> wrote:
> > > > > > > > > > Sorry.. worst than Draft Review: JSR 303 is in Draft
> Ballot
> > > yet!! So
> > > > > > > > > it'll
> > > > > > > > > > take some time until a final specification for this
> under
> > > JPA. :(
> > > > > > > > > >
> > > > > > > > > > Let's continue with HV ? :D
> > > > > > > > > It seems reasonable to me, but the opinion from Wicket
> team
> > > would be
> > > > > > > > > much more valuable than mine.
> > > > > > > > >
> > > > > > > > > Xavier
> > > > > > > > > >
> > > > > > > > > > []'s
> > > > > > > > > > --
> > > > > > > > > > Bruno Borges
> > > > > > > > > > Summa Technologies Inc.
> > > > > > > > > > www.summa-tech.com
> > > > > > > > > > (48) 8404-1300
> > > > > > > > > > (11) 3055-2060
> > > > > > > > > >
> > > > > > > > > > On 4/25/07, Bruno Borges <br...@gmail.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hibernate Validation is related to JSR 303<
> > > > > > > > > http://jcp.org/en/jsr/detail?id=303>,
> > > > > > > > > > > which is in draft review yet... :(
> > > > > > > > > > > And most probably HV will be used as RI with changes
> to
> > > JPA for
> > > > > > > sure.
> > > > > > > > > > > But maybe it can start as a contrib project, what'd
> you
> > > think?
> > > > > > > > > > >
> > > > > > > > > > > []'s
> > > > > > > > > > > --
> > > > > > > > > > > Bruno Borges
> > > > > > > > > > > Summa Technologies Inc.
> > > > > > > > > > > www.summa-tech.com
> > > > > > > > > > > (48) 8404-1300
> > > > > > > > > > > (11) 3055-2060
> > > > > > > > > > >
> > > > > > > > > > > On 4/25/07, Xavier Hanin <xa...@gmail.com>
> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > I haven't had time to check HV in depth for the
> moment
> > > but I've
> > > > > > > > > heard
> > > > > > > > > > > > good things about it, and was about to ask the same
> > > question as
> > > > > > > > > Bruno,
> > > > > > > > > > > > because I would be interested too in such a
> validator.
> > > > > > > > > > > >
> > > > > > > > > > > > Martijn, doesn't your proposition to rely on JPA
> spec
> > > instead of
> > > > > > > HV
> > > > > > > > > > > > imply to rewrite sg similar to what has been done in
> HV?
> > > > > > > > > > > >
> > > > > > > > > > > > Xavier
> > > > > > > > > > > >
> > > > > > > > > > > > On 4/25/07, Martijn Dashorst <
> martijn.dashorst@gmail.com>
> > > wrote:
> > > > > > > > > > > > > I would most like want this to be built against
> the
> > > JPA spec
> > > > > > > > > instead
> > > > > > > > > > > > > of directly implementing Hibernate's validators.
> Then
> > > we can
> > > > > > > use
> > > > > > > > > it
> > > > > > > > > > > > > for toplink, hibernate, openjpa, etc. And it is
> Apache
> > > license
> > > > > > > > > > > > > friendly too.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Martijn
> > > > > > > > > > > > >
> > > > > > > > > > > > > On 4/25/07, Bruno Borges < bruno.borges@gmail.com>
> > > wrote:
> > > > > > > > > > > > > > I was thinking of a Validator like the Ajax one.
> See
> > > this
> > > > > > > > > example:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > TextField email = new TextField("email");
> > > > > > > > > > > > > > email.add(new JPAValidator()); // or new
> > > JPAValidator(
> > > > > > > Pojo.class
> > > > > > > > > );
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > And the class scans the Model for annotated
> > > properties and
> > > > > > > adds
> > > > > > > > > the
> > > > > > > > > > > > related
> > > > > > > > > > > > > > Wicket validators automatically. If the Model is
> a
> > > POJO not
> > > > > > > > > > > > annotated with
> > > > > > > > > > > > > > @Entity, its possible to use JPAValidator(Class
> > > clazz);.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > @EmailValidation // a custom HV email's
> annotation
> > > pattern
> > > > > > > > > > > > > > public String getEmail() { return email; }
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > What you guys think about this? (I like to see
> the
> > > code I'd
> > > > > > > like
> > > > > > > > > to
> > > > > > > > > > > > use and
> > > > > > > > > > > > > > implement it around the examples... :D )
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > []'s
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > Bruno Borges
> > > > > > > > > > > > > > Summa Technologies Inc.
> > > > > > > > > > > > > > www.summa-tech.com
> > > > > > > > > > > > > > (48) 8404-1300
> > > > > > > > > > > > > > (11) 3055-2060
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On 4/24/07, Eelco Hillenius <
> > > eelco.hillenius@gmail.com>
> > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I've been thinking about it, haven't got
> around
> > > doing it.
> > > > > > > > > Should
> > > > > > > > > > > > be
> > > > > > > > > > > > > > > pretty easy to do, especially with our shiny
> new
> > > > > > > validators.
> > > > > > > > > Maybe
> > > > > > > > > > > > we
> > > > > > > > > > > > > > > can make this a shared effort?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Eelco
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On 4/24/07, Bruno Borges <
> bruno.borges@gmail.com >
> > > wrote:
> > > > > > > > > > > > > > > > Has anybody made an integration between
> Wicket
> > > and
> > > > > > > Hibernate
> > > > > > > > > > > > Validator?
> > > > > > > > > > > > > > > HV
> > > > > > > > > > > > > > > > is probably going to be the reference
> > > implementation for
> > > > > > > JSR
> > > > > > > > > 303
> > > > > > > > > > > > and
> > > > > > > > > > > > > > > JBoss
> > > > > > > > > > > > > > > > Seams use it integrated with JSF. Looks
> cool...
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > http://hibernate.org/412.html
> > > > > > > > > > > > > > > > http://jcp.org/en/jsr/detail?id=303
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Cheers
> > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > Bruno Borges
> > > > > > > > > > > > > > > > Summa Technologies Inc.
> > > > > > > > > > > > > > > > www.summa-tech.com
> > > > > > > > > > > > > > > > (48) 8404-1300
> > > > > > > > > > > > > > > > (11) 3055-2060
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Learn Wicket at ApacheCon Europe:
> http://apachecon.com
> > > > > > > > > > > > > Join the wicket community at irc.freenode.net:
> > > ##wicket
> > > > > > > > > > > > > Wicket 1.2.6 contains a very important fix.
> Download
> > > Wicket
> > > > > > > now!
> > > > > > > > > > > > > http://wicketframework.org
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
> > > > > > > > > > > > Manage your dependencies with Ivy!
> > > > > > > > > > > > http://incubator.apache.org/ivy/
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
> > > > > > > > > Manage your dependencies with Ivy!
> > > > > > > > > http://incubator.apache.org/ivy/
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
> > > > > > > Manage your dependencies with Ivy!
> > > > > > > http://incubator.apache.org/ivy/
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
> > > > > Manage your dependencies with Ivy!
> > > > > http://incubator.apache.org/ivy/
> > > > >
> > > >
> > >
> >
>
Re: Hibernate Validator integration?
Posted by Ryan Sonnek <ry...@gmail.com>.
Hey Bruno, I'd love to contribute. My experience with annotations and
hibernate validators is very limited, but I'd love to dig in. do you
have any place to start for source code? I'd like to start a small
project in wicket-stuff to try this out. do you have account setup
for wicket-stuff access?
On 5/8/07, Bruno Borges <br...@gmail.com> wrote:
> Ryan, want to work together on this?
>
> Regards,
> --
> Bruno Borges
> Summa Technologies Inc.
> www.summa-tech.com
> (48) 8404-1300
> (11) 3055-2060
>
> On 5/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > I think someone (you?) just has to take up the initiative. I think the
> > core team is too tight up atm.
> >
> > Eelco
> >
> >
> > On 5/8/07, Ryan Sonnek <ry...@gmail.com> wrote:
> > > I haven't heard anything on this thread for a while, and it seemed
> > > really exciting. Has there been any progress on creating a wicket
> > > validator that uses hibernate annotations? anything available in
> > > wicket-stuff to take a look at?
> > >
> > > On 4/25/07, Xavier Hanin <xa...@gmail.com> wrote:
> > > > On 4/25/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > > naah, we share this list with wicket-stuff. makes it easier.
> > > > Ok, sorry, next time I'll just put a +1 to give my opinion, it will
> > > > save a couple of emails :-)
> > > >
> > > > Xavier
> > > >
> > > > >
> > > > > -igor
> > > > >
> > > > >
> > > > > On 4/25/07, Xavier Hanin <xa...@gmail.com> wrote:
> > > > > >
> > > > > > On 4/25/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > > > > why would our opinion matter? you are free to start a
> > wicket-stuff
> > > > > > project
> > > > > > > to integrate whatever you want :)
> > > > > > Agreed, but since Bruno posted on the dev mailing list, I thought
> > he
> > > > > > was more specifically asking opinion from the wicket team.
> > > > > >
> > > > > > Xavier
> > > > > >
> > > > > > >
> > > > > > > -igor
> > > > > > >
> > > > > > >
> > > > > > > On 4/25/07, Xavier Hanin <xa...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On 4/25/07, Bruno Borges <br...@gmail.com> wrote:
> > > > > > > > > Sorry.. worst than Draft Review: JSR 303 is in Draft Ballot
> > yet!! So
> > > > > > > > it'll
> > > > > > > > > take some time until a final specification for this under
> > JPA. :(
> > > > > > > > >
> > > > > > > > > Let's continue with HV ? :D
> > > > > > > > It seems reasonable to me, but the opinion from Wicket team
> > would be
> > > > > > > > much more valuable than mine.
> > > > > > > >
> > > > > > > > Xavier
> > > > > > > > >
> > > > > > > > > []'s
> > > > > > > > > --
> > > > > > > > > Bruno Borges
> > > > > > > > > Summa Technologies Inc.
> > > > > > > > > www.summa-tech.com
> > > > > > > > > (48) 8404-1300
> > > > > > > > > (11) 3055-2060
> > > > > > > > >
> > > > > > > > > On 4/25/07, Bruno Borges <br...@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > Hibernate Validation is related to JSR 303<
> > > > > > > > http://jcp.org/en/jsr/detail?id=303>,
> > > > > > > > > > which is in draft review yet... :(
> > > > > > > > > > And most probably HV will be used as RI with changes to
> > JPA for
> > > > > > sure.
> > > > > > > > > > But maybe it can start as a contrib project, what'd you
> > think?
> > > > > > > > > >
> > > > > > > > > > []'s
> > > > > > > > > > --
> > > > > > > > > > Bruno Borges
> > > > > > > > > > Summa Technologies Inc.
> > > > > > > > > > www.summa-tech.com
> > > > > > > > > > (48) 8404-1300
> > > > > > > > > > (11) 3055-2060
> > > > > > > > > >
> > > > > > > > > > On 4/25/07, Xavier Hanin <xa...@gmail.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > I haven't had time to check HV in depth for the moment
> > but I've
> > > > > > > > heard
> > > > > > > > > > > good things about it, and was about to ask the same
> > question as
> > > > > > > > Bruno,
> > > > > > > > > > > because I would be interested too in such a validator.
> > > > > > > > > > >
> > > > > > > > > > > Martijn, doesn't your proposition to rely on JPA spec
> > instead of
> > > > > > HV
> > > > > > > > > > > imply to rewrite sg similar to what has been done in HV?
> > > > > > > > > > >
> > > > > > > > > > > Xavier
> > > > > > > > > > >
> > > > > > > > > > > On 4/25/07, Martijn Dashorst <ma...@gmail.com>
> > wrote:
> > > > > > > > > > > > I would most like want this to be built against the
> > JPA spec
> > > > > > > > instead
> > > > > > > > > > > > of directly implementing Hibernate's validators. Then
> > we can
> > > > > > use
> > > > > > > > it
> > > > > > > > > > > > for toplink, hibernate, openjpa, etc. And it is Apache
> > license
> > > > > > > > > > > > friendly too.
> > > > > > > > > > > >
> > > > > > > > > > > > Martijn
> > > > > > > > > > > >
> > > > > > > > > > > > On 4/25/07, Bruno Borges < bruno.borges@gmail.com>
> > wrote:
> > > > > > > > > > > > > I was thinking of a Validator like the Ajax one. See
> > this
> > > > > > > > example:
> > > > > > > > > > > > >
> > > > > > > > > > > > > TextField email = new TextField("email");
> > > > > > > > > > > > > email.add(new JPAValidator()); // or new
> > JPAValidator(
> > > > > > Pojo.class
> > > > > > > > );
> > > > > > > > > > > > >
> > > > > > > > > > > > > And the class scans the Model for annotated
> > properties and
> > > > > > adds
> > > > > > > > the
> > > > > > > > > > > related
> > > > > > > > > > > > > Wicket validators automatically. If the Model is a
> > POJO not
> > > > > > > > > > > annotated with
> > > > > > > > > > > > > @Entity, its possible to use JPAValidator(Class
> > clazz);.
> > > > > > > > > > > > >
> > > > > > > > > > > > > @EmailValidation // a custom HV email's annotation
> > pattern
> > > > > > > > > > > > > public String getEmail() { return email; }
> > > > > > > > > > > > >
> > > > > > > > > > > > > What you guys think about this? (I like to see the
> > code I'd
> > > > > > like
> > > > > > > > to
> > > > > > > > > > > use and
> > > > > > > > > > > > > implement it around the examples... :D )
> > > > > > > > > > > > >
> > > > > > > > > > > > > []'s
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Bruno Borges
> > > > > > > > > > > > > Summa Technologies Inc.
> > > > > > > > > > > > > www.summa-tech.com
> > > > > > > > > > > > > (48) 8404-1300
> > > > > > > > > > > > > (11) 3055-2060
> > > > > > > > > > > > >
> > > > > > > > > > > > > On 4/24/07, Eelco Hillenius <
> > eelco.hillenius@gmail.com>
> > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I've been thinking about it, haven't got around
> > doing it.
> > > > > > > > Should
> > > > > > > > > > > be
> > > > > > > > > > > > > > pretty easy to do, especially with our shiny new
> > > > > > validators.
> > > > > > > > Maybe
> > > > > > > > > > > we
> > > > > > > > > > > > > > can make this a shared effort?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Eelco
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On 4/24/07, Bruno Borges <bruno.borges@gmail.com >
> > wrote:
> > > > > > > > > > > > > > > Has anybody made an integration between Wicket
> > and
> > > > > > Hibernate
> > > > > > > > > > > Validator?
> > > > > > > > > > > > > > HV
> > > > > > > > > > > > > > > is probably going to be the reference
> > implementation for
> > > > > > JSR
> > > > > > > > 303
> > > > > > > > > > > and
> > > > > > > > > > > > > > JBoss
> > > > > > > > > > > > > > > Seams use it integrated with JSF. Looks cool...
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > http://hibernate.org/412.html
> > > > > > > > > > > > > > > http://jcp.org/en/jsr/detail?id=303
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Cheers
> > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > Bruno Borges
> > > > > > > > > > > > > > > Summa Technologies Inc.
> > > > > > > > > > > > > > > www.summa-tech.com
> > > > > > > > > > > > > > > (48) 8404-1300
> > > > > > > > > > > > > > > (11) 3055-2060
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > Learn Wicket at ApacheCon Europe: http://apachecon.com
> > > > > > > > > > > > Join the wicket community at irc.freenode.net:
> > ##wicket
> > > > > > > > > > > > Wicket 1.2.6 contains a very important fix. Download
> > Wicket
> > > > > > now!
> > > > > > > > > > > > http://wicketframework.org
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
> > > > > > > > > > > Manage your dependencies with Ivy!
> > > > > > > > > > > http://incubator.apache.org/ivy/
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
> > > > > > > > Manage your dependencies with Ivy!
> > > > > > > > http://incubator.apache.org/ivy/
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
> > > > > > Manage your dependencies with Ivy!
> > > > > > http://incubator.apache.org/ivy/
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
> > > > Manage your dependencies with Ivy!
> > > > http://incubator.apache.org/ivy/
> > > >
> > >
> >
>
Re: Hibernate Validator integration?
Posted by Bruno Borges <br...@gmail.com>.
Ryan, want to work together on this?
Regards,
--
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(48) 8404-1300
(11) 3055-2060
On 5/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> I think someone (you?) just has to take up the initiative. I think the
> core team is too tight up atm.
>
> Eelco
>
>
> On 5/8/07, Ryan Sonnek <ry...@gmail.com> wrote:
> > I haven't heard anything on this thread for a while, and it seemed
> > really exciting. Has there been any progress on creating a wicket
> > validator that uses hibernate annotations? anything available in
> > wicket-stuff to take a look at?
> >
> > On 4/25/07, Xavier Hanin <xa...@gmail.com> wrote:
> > > On 4/25/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > naah, we share this list with wicket-stuff. makes it easier.
> > > Ok, sorry, next time I'll just put a +1 to give my opinion, it will
> > > save a couple of emails :-)
> > >
> > > Xavier
> > >
> > > >
> > > > -igor
> > > >
> > > >
> > > > On 4/25/07, Xavier Hanin <xa...@gmail.com> wrote:
> > > > >
> > > > > On 4/25/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > > > why would our opinion matter? you are free to start a
> wicket-stuff
> > > > > project
> > > > > > to integrate whatever you want :)
> > > > > Agreed, but since Bruno posted on the dev mailing list, I thought
> he
> > > > > was more specifically asking opinion from the wicket team.
> > > > >
> > > > > Xavier
> > > > >
> > > > > >
> > > > > > -igor
> > > > > >
> > > > > >
> > > > > > On 4/25/07, Xavier Hanin <xa...@gmail.com> wrote:
> > > > > > >
> > > > > > > On 4/25/07, Bruno Borges <br...@gmail.com> wrote:
> > > > > > > > Sorry.. worst than Draft Review: JSR 303 is in Draft Ballot
> yet!! So
> > > > > > > it'll
> > > > > > > > take some time until a final specification for this under
> JPA. :(
> > > > > > > >
> > > > > > > > Let's continue with HV ? :D
> > > > > > > It seems reasonable to me, but the opinion from Wicket team
> would be
> > > > > > > much more valuable than mine.
> > > > > > >
> > > > > > > Xavier
> > > > > > > >
> > > > > > > > []'s
> > > > > > > > --
> > > > > > > > Bruno Borges
> > > > > > > > Summa Technologies Inc.
> > > > > > > > www.summa-tech.com
> > > > > > > > (48) 8404-1300
> > > > > > > > (11) 3055-2060
> > > > > > > >
> > > > > > > > On 4/25/07, Bruno Borges <br...@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > Hibernate Validation is related to JSR 303<
> > > > > > > http://jcp.org/en/jsr/detail?id=303>,
> > > > > > > > > which is in draft review yet... :(
> > > > > > > > > And most probably HV will be used as RI with changes to
> JPA for
> > > > > sure.
> > > > > > > > > But maybe it can start as a contrib project, what'd you
> think?
> > > > > > > > >
> > > > > > > > > []'s
> > > > > > > > > --
> > > > > > > > > Bruno Borges
> > > > > > > > > Summa Technologies Inc.
> > > > > > > > > www.summa-tech.com
> > > > > > > > > (48) 8404-1300
> > > > > > > > > (11) 3055-2060
> > > > > > > > >
> > > > > > > > > On 4/25/07, Xavier Hanin <xa...@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > I haven't had time to check HV in depth for the moment
> but I've
> > > > > > > heard
> > > > > > > > > > good things about it, and was about to ask the same
> question as
> > > > > > > Bruno,
> > > > > > > > > > because I would be interested too in such a validator.
> > > > > > > > > >
> > > > > > > > > > Martijn, doesn't your proposition to rely on JPA spec
> instead of
> > > > > HV
> > > > > > > > > > imply to rewrite sg similar to what has been done in HV?
> > > > > > > > > >
> > > > > > > > > > Xavier
> > > > > > > > > >
> > > > > > > > > > On 4/25/07, Martijn Dashorst <ma...@gmail.com>
> wrote:
> > > > > > > > > > > I would most like want this to be built against the
> JPA spec
> > > > > > > instead
> > > > > > > > > > > of directly implementing Hibernate's validators. Then
> we can
> > > > > use
> > > > > > > it
> > > > > > > > > > > for toplink, hibernate, openjpa, etc. And it is Apache
> license
> > > > > > > > > > > friendly too.
> > > > > > > > > > >
> > > > > > > > > > > Martijn
> > > > > > > > > > >
> > > > > > > > > > > On 4/25/07, Bruno Borges < bruno.borges@gmail.com>
> wrote:
> > > > > > > > > > > > I was thinking of a Validator like the Ajax one. See
> this
> > > > > > > example:
> > > > > > > > > > > >
> > > > > > > > > > > > TextField email = new TextField("email");
> > > > > > > > > > > > email.add(new JPAValidator()); // or new
> JPAValidator(
> > > > > Pojo.class
> > > > > > > );
> > > > > > > > > > > >
> > > > > > > > > > > > And the class scans the Model for annotated
> properties and
> > > > > adds
> > > > > > > the
> > > > > > > > > > related
> > > > > > > > > > > > Wicket validators automatically. If the Model is a
> POJO not
> > > > > > > > > > annotated with
> > > > > > > > > > > > @Entity, its possible to use JPAValidator(Class
> clazz);.
> > > > > > > > > > > >
> > > > > > > > > > > > @EmailValidation // a custom HV email's annotation
> pattern
> > > > > > > > > > > > public String getEmail() { return email; }
> > > > > > > > > > > >
> > > > > > > > > > > > What you guys think about this? (I like to see the
> code I'd
> > > > > like
> > > > > > > to
> > > > > > > > > > use and
> > > > > > > > > > > > implement it around the examples... :D )
> > > > > > > > > > > >
> > > > > > > > > > > > []'s
> > > > > > > > > > > > --
> > > > > > > > > > > > Bruno Borges
> > > > > > > > > > > > Summa Technologies Inc.
> > > > > > > > > > > > www.summa-tech.com
> > > > > > > > > > > > (48) 8404-1300
> > > > > > > > > > > > (11) 3055-2060
> > > > > > > > > > > >
> > > > > > > > > > > > On 4/24/07, Eelco Hillenius <
> eelco.hillenius@gmail.com>
> > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > I've been thinking about it, haven't got around
> doing it.
> > > > > > > Should
> > > > > > > > > > be
> > > > > > > > > > > > > pretty easy to do, especially with our shiny new
> > > > > validators.
> > > > > > > Maybe
> > > > > > > > > > we
> > > > > > > > > > > > > can make this a shared effort?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Eelco
> > > > > > > > > > > > >
> > > > > > > > > > > > > On 4/24/07, Bruno Borges <bruno.borges@gmail.com >
> wrote:
> > > > > > > > > > > > > > Has anybody made an integration between Wicket
> and
> > > > > Hibernate
> > > > > > > > > > Validator?
> > > > > > > > > > > > > HV
> > > > > > > > > > > > > > is probably going to be the reference
> implementation for
> > > > > JSR
> > > > > > > 303
> > > > > > > > > > and
> > > > > > > > > > > > > JBoss
> > > > > > > > > > > > > > Seams use it integrated with JSF. Looks cool...
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > http://hibernate.org/412.html
> > > > > > > > > > > > > > http://jcp.org/en/jsr/detail?id=303
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Cheers
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > Bruno Borges
> > > > > > > > > > > > > > Summa Technologies Inc.
> > > > > > > > > > > > > > www.summa-tech.com
> > > > > > > > > > > > > > (48) 8404-1300
> > > > > > > > > > > > > > (11) 3055-2060
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Learn Wicket at ApacheCon Europe: http://apachecon.com
> > > > > > > > > > > Join the wicket community at irc.freenode.net:
> ##wicket
> > > > > > > > > > > Wicket 1.2.6 contains a very important fix. Download
> Wicket
> > > > > now!
> > > > > > > > > > > http://wicketframework.org
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
> > > > > > > > > > Manage your dependencies with Ivy!
> > > > > > > > > > http://incubator.apache.org/ivy/
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
> > > > > > > Manage your dependencies with Ivy!
> > > > > > > http://incubator.apache.org/ivy/
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
> > > > > Manage your dependencies with Ivy!
> > > > > http://incubator.apache.org/ivy/
> > > > >
> > > >
> > >
> > >
> > > --
> > > Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
> > > Manage your dependencies with Ivy!
> > > http://incubator.apache.org/ivy/
> > >
> >
>
Re: Hibernate Validator integration?
Posted by Eelco Hillenius <ee...@gmail.com>.
I think someone (you?) just has to take up the initiative. I think the
core team is too tight up atm.
Eelco
On 5/8/07, Ryan Sonnek <ry...@gmail.com> wrote:
> I haven't heard anything on this thread for a while, and it seemed
> really exciting. Has there been any progress on creating a wicket
> validator that uses hibernate annotations? anything available in
> wicket-stuff to take a look at?
>
> On 4/25/07, Xavier Hanin <xa...@gmail.com> wrote:
> > On 4/25/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > naah, we share this list with wicket-stuff. makes it easier.
> > Ok, sorry, next time I'll just put a +1 to give my opinion, it will
> > save a couple of emails :-)
> >
> > Xavier
> >
> > >
> > > -igor
> > >
> > >
> > > On 4/25/07, Xavier Hanin <xa...@gmail.com> wrote:
> > > >
> > > > On 4/25/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > > why would our opinion matter? you are free to start a wicket-stuff
> > > > project
> > > > > to integrate whatever you want :)
> > > > Agreed, but since Bruno posted on the dev mailing list, I thought he
> > > > was more specifically asking opinion from the wicket team.
> > > >
> > > > Xavier
> > > >
> > > > >
> > > > > -igor
> > > > >
> > > > >
> > > > > On 4/25/07, Xavier Hanin <xa...@gmail.com> wrote:
> > > > > >
> > > > > > On 4/25/07, Bruno Borges <br...@gmail.com> wrote:
> > > > > > > Sorry.. worst than Draft Review: JSR 303 is in Draft Ballot yet!! So
> > > > > > it'll
> > > > > > > take some time until a final specification for this under JPA. :(
> > > > > > >
> > > > > > > Let's continue with HV ? :D
> > > > > > It seems reasonable to me, but the opinion from Wicket team would be
> > > > > > much more valuable than mine.
> > > > > >
> > > > > > Xavier
> > > > > > >
> > > > > > > []'s
> > > > > > > --
> > > > > > > Bruno Borges
> > > > > > > Summa Technologies Inc.
> > > > > > > www.summa-tech.com
> > > > > > > (48) 8404-1300
> > > > > > > (11) 3055-2060
> > > > > > >
> > > > > > > On 4/25/07, Bruno Borges <br...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Hibernate Validation is related to JSR 303<
> > > > > > http://jcp.org/en/jsr/detail?id=303>,
> > > > > > > > which is in draft review yet... :(
> > > > > > > > And most probably HV will be used as RI with changes to JPA for
> > > > sure.
> > > > > > > > But maybe it can start as a contrib project, what'd you think?
> > > > > > > >
> > > > > > > > []'s
> > > > > > > > --
> > > > > > > > Bruno Borges
> > > > > > > > Summa Technologies Inc.
> > > > > > > > www.summa-tech.com
> > > > > > > > (48) 8404-1300
> > > > > > > > (11) 3055-2060
> > > > > > > >
> > > > > > > > On 4/25/07, Xavier Hanin <xa...@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > I haven't had time to check HV in depth for the moment but I've
> > > > > > heard
> > > > > > > > > good things about it, and was about to ask the same question as
> > > > > > Bruno,
> > > > > > > > > because I would be interested too in such a validator.
> > > > > > > > >
> > > > > > > > > Martijn, doesn't your proposition to rely on JPA spec instead of
> > > > HV
> > > > > > > > > imply to rewrite sg similar to what has been done in HV?
> > > > > > > > >
> > > > > > > > > Xavier
> > > > > > > > >
> > > > > > > > > On 4/25/07, Martijn Dashorst <ma...@gmail.com> wrote:
> > > > > > > > > > I would most like want this to be built against the JPA spec
> > > > > > instead
> > > > > > > > > > of directly implementing Hibernate's validators. Then we can
> > > > use
> > > > > > it
> > > > > > > > > > for toplink, hibernate, openjpa, etc. And it is Apache license
> > > > > > > > > > friendly too.
> > > > > > > > > >
> > > > > > > > > > Martijn
> > > > > > > > > >
> > > > > > > > > > On 4/25/07, Bruno Borges < bruno.borges@gmail.com> wrote:
> > > > > > > > > > > I was thinking of a Validator like the Ajax one. See this
> > > > > > example:
> > > > > > > > > > >
> > > > > > > > > > > TextField email = new TextField("email");
> > > > > > > > > > > email.add(new JPAValidator()); // or new JPAValidator(
> > > > Pojo.class
> > > > > > );
> > > > > > > > > > >
> > > > > > > > > > > And the class scans the Model for annotated properties and
> > > > adds
> > > > > > the
> > > > > > > > > related
> > > > > > > > > > > Wicket validators automatically. If the Model is a POJO not
> > > > > > > > > annotated with
> > > > > > > > > > > @Entity, its possible to use JPAValidator(Class clazz);.
> > > > > > > > > > >
> > > > > > > > > > > @EmailValidation // a custom HV email's annotation pattern
> > > > > > > > > > > public String getEmail() { return email; }
> > > > > > > > > > >
> > > > > > > > > > > What you guys think about this? (I like to see the code I'd
> > > > like
> > > > > > to
> > > > > > > > > use and
> > > > > > > > > > > implement it around the examples... :D )
> > > > > > > > > > >
> > > > > > > > > > > []'s
> > > > > > > > > > > --
> > > > > > > > > > > Bruno Borges
> > > > > > > > > > > Summa Technologies Inc.
> > > > > > > > > > > www.summa-tech.com
> > > > > > > > > > > (48) 8404-1300
> > > > > > > > > > > (11) 3055-2060
> > > > > > > > > > >
> > > > > > > > > > > On 4/24/07, Eelco Hillenius < eelco.hillenius@gmail.com>
> > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > I've been thinking about it, haven't got around doing it.
> > > > > > Should
> > > > > > > > > be
> > > > > > > > > > > > pretty easy to do, especially with our shiny new
> > > > validators.
> > > > > > Maybe
> > > > > > > > > we
> > > > > > > > > > > > can make this a shared effort?
> > > > > > > > > > > >
> > > > > > > > > > > > Eelco
> > > > > > > > > > > >
> > > > > > > > > > > > On 4/24/07, Bruno Borges <bruno.borges@gmail.com > wrote:
> > > > > > > > > > > > > Has anybody made an integration between Wicket and
> > > > Hibernate
> > > > > > > > > Validator?
> > > > > > > > > > > > HV
> > > > > > > > > > > > > is probably going to be the reference implementation for
> > > > JSR
> > > > > > 303
> > > > > > > > > and
> > > > > > > > > > > > JBoss
> > > > > > > > > > > > > Seams use it integrated with JSF. Looks cool...
> > > > > > > > > > > > >
> > > > > > > > > > > > > http://hibernate.org/412.html
> > > > > > > > > > > > > http://jcp.org/en/jsr/detail?id=303
> > > > > > > > > > > > >
> > > > > > > > > > > > > Cheers
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Bruno Borges
> > > > > > > > > > > > > Summa Technologies Inc.
> > > > > > > > > > > > > www.summa-tech.com
> > > > > > > > > > > > > (48) 8404-1300
> > > > > > > > > > > > > (11) 3055-2060
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Learn Wicket at ApacheCon Europe: http://apachecon.com
> > > > > > > > > > Join the wicket community at irc.freenode.net: ##wicket
> > > > > > > > > > Wicket 1.2.6 contains a very important fix. Download Wicket
> > > > now!
> > > > > > > > > > http://wicketframework.org
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
> > > > > > > > > Manage your dependencies with Ivy!
> > > > > > > > > http://incubator.apache.org/ivy/
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
> > > > > > Manage your dependencies with Ivy!
> > > > > > http://incubator.apache.org/ivy/
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
> > > > Manage your dependencies with Ivy!
> > > > http://incubator.apache.org/ivy/
> > > >
> > >
> >
> >
> > --
> > Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
> > Manage your dependencies with Ivy!
> > http://incubator.apache.org/ivy/
> >
>