actually another advantage of doing this, as far as hibernate validator
stuff goes, is that because it is a behavior and validator in one the
validator can get access to the component it is attached to via
behavior.bind().

-igor


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
>


Reply via email to