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
> >
>
