[x] All above
--
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(48) 8404-1300
(11) 3055-2060
On 5/10/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
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
> > > >
> > >
> >
>
