That's what we have/ had. You let IValidator extend IBehaviorProvider and then implement newValidatorBehavior.
Eelco On 5/10/07, Bruno Borges <[EMAIL PROTECTED]> wrote:
Why don't let IValidator has its own behavior if it wants to. IValidator.getBehavior() Behavior goes on the client-side, right? (I'm still a little confused about all these interfaces...) Isn't this ok ? If not, why? -- Bruno Borges Summa Technologies Inc. www.summa-tech.com (48) 8404-1300 (11) 3055-2060 On 5/10/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > On 5/10/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > 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. > > > yes, i thought about this. doing add((IBehavior)foo) would be annoying. we > need to think about how to solve it. maybe not have overloaded add > methods, > or have a convinience addValidator() in addition to both add() methods. > dont > know yet. > > 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. > > > i dont really like the above either. there isnt anything in common you can > extract, they are orthogonal classes. > > 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. > > > not really, it is much easier with my adapter. > add(new ValidatorAndBehavior(new MaxLengthValidator(5), new > AjaxBehavior()); > add(new ValidatorAndBehavior(new MaxLengthValidator(5), new > MaxLenSetter()); > > > otherwise you would have to have a subclass of maxlengthvalidator that > allows you to set a behavior, or make it anonymous. the adapter can link > arbitrary behaviors with less loc. > > 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. > > > ah, but that we can check. when they add a behavior that is also a > ivalidator to a non formcomponent we can throw an exception. > > -igor > > > > > 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 > > >
