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
> >
>
