Have any of you seen this code<http://wicket-stuff.svn.sourceforge.net/viewvc/wicket-stuff/trunk/wicketstuff-hibernate-behavior/src/main/java/org/wicketstuff/hibernate/validator/HibernateFormComponentValidator.java?revision=2096&view=markup>I commited?
There are some comments in it to discuss about. []'s -- Bruno Borges Summa Technologies Inc. www.summa-tech.com (48) 8404-1300 (11) 3055-2060 On 5/10/07, Bruno Borges <[EMAIL PROTECTED]> wrote:
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 > > > > > > > > > >
