I'm a little confused on how these changes would impact the hibernate
integration. anyone care to spell out how this changes the code?
On 5/9/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Sounds good to me.
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
> >
>
