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
