Cool. This can do the job. :) Dummy question: why newValidationBehavior and not just newBehavior ? :D
[]' s! -- Bruno Borges Summa Technologies Inc. www.summa-tech.com (48) 8404-1300 (11) 3055-2060 On 5/10/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
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 > > > > > >
