If we are talking about client side validators: then you want support for 2
behaviors that are attached to "blur" and "onchange" ?
or one client side javascript check and an ajax call to the behavior?
Or are there others that you have in mind?
johan
On 5/10/07, Bruno Borges <[EMAIL PROTECTED]> wrote:
What if we want to have in one IValidator, more than one IBehavior? just
wondering... :)
This could be important and usefull, if in one Validator two _very simple_
behaviors are needed, and they need to be keep separated with each other.
[]'s
--
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(48) 8404-1300
(11) 3055-2060
On 5/10/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
>
> and i don't like that
> that is mixing 2 classes as once thing
> that means no reuse what so ever. This just makes big copy paste
actions.
>
> it should be possible to seperate IValidator and IBehavior
implementations
> else if i want to use an IValidator i have to reimplement it
> yes ofcourse i can make my behavior implement also IValidator
> and then passthrough everything of the IValidtor to the real validator
> that
> is again a delegate.
>
> we just don't have multiply inheritance in java..
>
> having a IValidator provide a IBehavior is much nicer in my eyes
>
> johan
>
>
> On 5/10/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> >
> > 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.
> >
> > my two cents
> >
> > -igor
> >
> >
> > On 5/9/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> > >
> > > > no. dont forget that the idea of IValidator is to be decoupled
from
> > > wicket,
> > > > to allow the reuse of validators in service layer. i do that all
the
> > > time
> > > > now and it rocks! my service layer and my ui layer are validated
by
> > the
> > > same
> > > > code. adding ivalidator.getbehavior() will break all that nice
> > > decoupling.
> > > >
> > > > i always thought that something like this would work
> > > >
> > > > IClientSideValidator extends IValidator { /** rerturn a js func to
> > > validate
> > > > the value */ CharSequence getValidationScript(); }
> > >
> > > /**
> > > * Validator that provides a behavior, e.g. for rendering client-side
> or
> > > ajax
> > > * validation. This interface can be implemented by either
> > > * [EMAIL PROTECTED] IValidator validators} or [EMAIL PROTECTED]
IFormValidator form
> > validators}.
> > > */
> > > public interface IBehaviorProvider extends IClusterable
> > > {
> > > /**
> > > * Gets behavior for validation.
> > > *
> > > * @param component
> > > * component currently using the validator
> > > * @return The behavior, which can be used for rendering e.g
.
> > > */
> > > IBehavior getValidationBehavior(Component component);
> > > }
> > >
> > > same here, instanceof check and ready. Not extra code as how to
> > > interpret it, and all the flexibility that behaviors provide.
> > >
> > > Eelco
> > >
> >
>
