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