To follow with onAttach/onDetach (I don't remember if these has -ed)
--
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(48) 8404-1300
(11) 3055-2060
On 5/11/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
so why is it onadded() here and bind() in ibehavior?
-igor
On 5/11/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> I guess sitting back is not my strongest point :)
>
> I just committed a variant of Al's idea:
>
> /**
> * Optional interface for validators ([EMAIL PROTECTED] IValidator} and
> * [EMAIL PROTECTED] IFormValidator}) that can react to validators being added
to a
> * component.
> * <p>
> * Implementation note: currently we keep this case simple stupid
> non-generic.
> * In future versions we may revisit this and support removal events
(WHEN
> * removal of validators is ever allowed, which justifies it's own
> discussion).
> * Also, we may look at whether this is a common event to support for
> behaviors
> * as well. This raises additional questions that need to be answered,
> hence
> * we'll start by supporting just the use case when validators are added
to
> * forms or form components.
> * </p>
> */
> public interface IValidatorAddListener extends IClusterable
> {
> /**
> * Called right after a validator was added to a [EMAIL PROTECTED]
Form} or
> * [EMAIL PROTECTED] FormComponent}. A common use case for
implementing
this
> interface
> * is for validators to add behaviors to implement client side
> validation
> * capabilities, e.g. through JavaScript, Ajax or just by adding
a
> simple
> * attribute modifier that sets a maxlength attribute.
> *
> * @param component
> * component to which the validator was just added.
> */
> void onAdded(Component component);
> }
>
> for which you can have an implementation like:
>
> private static class MaxLengthValidator extends
> StringValidator.MaximumLengthValidator
> implements
> IValidatorAddListener
> {
> public MaxLengthValidator(int maximum)
> {
> super(maximum);
> }
>
> public void onAdded(Component component)
> {
> if (component instanceof AbstractTextComponent)
> {
> component.add(new
> SimpleAttributeModifier("maxlength",
> String.valueOf(getMaximum())));
> }
> }
> }
>
>
> Eelco
>
>
> On 5/11/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> > Well, if you feel strongly about this, maybe it is time to open
> > another discussion about this specifically or (maybe better as we're
> > having to digest lots of traffic to start with) a JIRA feature
> > request.
> >
> > Eelco
> >
> > On 5/11/07, Bruno Borges <[EMAIL PROTECTED]> wrote:
> > > Because Wicket is component based... :) We actually reuse components
> and
> > > somewhere we want to disable validators. For example: chained
> components
> > > where one component if selected, must disable another component's
> validator.
> > >
> > > --
> > > Bruno Borges
> > > Summa Technologies Inc.
> > > www.summa-tech.com
> > > (48) 8404-1300
> > > (11) 3055-2060
> > >
> > > On 5/11/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > How about enabled/disabled validators (and their behaviors) ?
This
> way,
> > > > no
> > > > > counting down is needed and when validatores are disabled, they
> > > > propagate
> > > > > this state to behaviors. Removing validators is strange to me,
but
> > > > disabling
> > > > > them for a while, I think this is more reasonable.
> > > >
> > > > Maybe. Again would be more in line with behaviors. But now the
> million
> > > > dollar question: for what use case? When would you actually ever
> need
> > > > to remove or disable a validator? And *if* you would ever need
such
> an
> > > > exotic case, why does Wicket have to do this for you and why don't
> we
> > > > tell people to just make this part of the way they implement their
> > > > validation method?
> > > >
> > > > Eelco
> > > >
> > >
> >
>
