hrm. after looking at it i dont like it :|

ivalidator is a pretty simple interface. why not simply allow a behavior to
implement it

add(ivalidator v) {
  if (v instanceof ibehavior) { add((ibehavior)v); }
  ...
}

so now a behavior can implement ivalidator. the problem that
ibehaviorprovider tries to solve is to allow one to glue any ivalidator with
any ibehavior. well, that can very simply be done with an adapter class that
simply delegates to the right delegate

class ValidatorWithBehavior implements IBehavior,IValidator{
   private IBehavior behavior;
   private IValidator validator;
   public ValidatorWithBehavior(IValidator v, IBehavior b) {
this.behavior=b;this.validator=v;
}
   ...delegating methods...
 }

this way we do not need IBehaviorProvider. we make behaviors and validators
more flexible because a behavior can also be a validator. there is no
removeBehavior/removeValidator problem because they are the same instance
and only exist once.

This is (of course) the first solution I worked on, and in fact the
solution I preferred up to yesterday (and maybe still prefer, not
sure). It needed some API changes though, as currently you can't have
a class that implements both interfaces and use add to call it. What I
did was substract a common interface (in fact broken up in some sub
interfaces, so that potentially IValidators can detach for instance),
and change add's signature to use that. However, when I showed that to
Johan, he has two objections. One was that he didn't like the tight
coupling, and rather would have a situation where for one component,
it would return an ajax behavior, and for another an attribute
modifier etc. This is easier with the current implementation. Another
thing was - and I agree with that - that the common interface results
in the API being less discoverable, and also would potentially open up
our API for people coming up with weird mix-ins and expecting
everything to work. Like adding a validator to a non-form component
for instance.

Anyway, Johan convinced me this was a better approach. But we're still
in the discovery stage. Johan, you want to chip in with your 2 c?

Eelco

Reply via email to