On 5/11/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Now Igor in particular has a problem with this solution as he likes the alternative (which I actually implemented at first, but didn't commit) where you can simply code classes that are both a validator and a behavior (implement IValidator or IFormValidator and IBehavior).
Long term, I think this is the "correct" solution as well. I do agree with your points though that this leads to a more "sweeping" change that affects a lot of the core framework.
The technical issue with that is that we have an add method for both, while they have a different hierarchy, so unless you do a hard cast, it's not going to work. And even if you do a hard cast, behaviors and validators are currently stored in their own structures, so either the add methods would have to be aware that a behavior can also be a validator (detail: validators currently are only known by form components, so add(IBehavior) would have to do some instanceof checking on itself to get this working) and that a validator can be a behavior in the add(I(Form)Validator) method.
Yuk. If they "really" share a common interface, their should not be two separate "add" APIs. overloading the add method for two very different purposes is a very bad idea IMO. I think this should be changed regardless of this new feature.
A way to fix this is to create a common interface (in my implementation I called this IComponentFacet) for IBehavior and IValidator and have one add method. In the mechanism I implemented, facets were stored in the same structure (so the validators field in FormComponent was removed) and it worked with a lookup method like getFacets(Class).
I agree with Al that seeing an IDE autocomplete a "Facet" instead of "Behavior" or "Validator" is a really big deal. I don't think it's worth it right now.
I guess my point is made. I'll back off for a bit and see what other people have to say about this. Anyone's opinions are welcome, and core developers, please contribute so that we can make this decision in consensus.
KISS. Keep It Simple (Stupid) :) The current solution is simple, but I thought there were objections because the Validator API is fairly independent of the internal wicket? I know you have to use this new optional interface, but it makes perfect sense for some of the core wicket validators to start using this feature ASAP. The max-length validator is a perfect example where this feature is needed. Start small, and don't try to support every usecase. IMO, getting the ball rolling with the max-length validation is a great start. Ryan
