I just committed the first pass without what you proposed yet. Maybe
you can take a look at that Igor?
I kept the mechanism as simple as I could. At a later stage, we can
see whether we need to optimize (e.g. by not keeping references to the
behaviors) though the simplicity of this solution has something going
for it as well.
Eelco
On 5/9/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
what about making iformvalidator extend ivalidator. and ibehaviorprovider
extend ivalidator.
in formvalidator validatable.value can be form.modelobject() and
validatable.error reports an error on form.
-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
>
