we will gladly accept a package.html to drop into wicket.validator :)
-igor
On 5/9/07, Jon Steelman <[EMAIL PROTECTED]> 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 <[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
> > >
> >
>
