The more I think about this, the more I think that a Validator IS-A Behavior. Here's why:
* wicket has a very robust behavior infrastructure. The validation framework is (intentionally) very minimalist * there are a *million* other java libraries that do validation. If wicket wants to promote it's own validation library, it needs to be broken out as a separate project altogether. I think it would be best for IValidator to extend from IBehavior. That way, any validator can *choose* to perform like a behavior as well. This removes the need for separate add(Behavior) and add(Validator) methods. The FormComponent can loop through the behaviors and do an instanceof check to see if the Behavior is a Validator. Again, I don't see this as bloating the Validator framework. Since there are so many validation frameworks out there, I use wicket for my web project, not for end-to-end validation. On 5/11/07, Ryan Sonnek <[EMAIL PROTECTED]> wrote:
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
