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