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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>
