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 >
