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
> >
>
