> 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.
I wouldn't call it IBehaviorProvider if it's tied into validators. ;-)
Perhaps call it IBehaviorProvidingValidator and make it extend
IValidator, so it's more obvious what's going on and what the interface
is for.
That said, I think I prefer this approach to IComponentFacet for the
following reasons:
- When a user goes CTRL+SPACE in Eclipse on their component, having an
add(IComponentFacet) method will be much more confusing and less
discoverable than add(IBehavior) and add(IValidator) methods.
As a newbie I'd be thinking, "what the hell is a facet?" whereas at
least "validator" is pretty self-explanatory.
- Conceptually, users are adding a validator. The fact that it adds a
behavior to help prevent invalid input or add feedback or whatever is
secondary to its main purpose, which is validation. It therefore
makes more sense to me that it's an IValidator first and foremost.
Putting IBehavior on a level footing with that doesn't make much
sense to me if I'm wearing my user hat.
- It's nice and simple - I don't have to think hard about whether it
might suck or not. ;-)
Cheers. I'd also like to pull in what you proposed in another thread,
which is to introduce a more generic hook. E.g.
public interface IValidationBindListener {
void onAdded(Component component);
void onRemoved(Component component);
}
It would still need to be a separate interface to avoid tight coupling
between validators and components (as we like validators to be useful
outside of Wicket as well at some point).
WDYT?
Eelco
