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.
--
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(48) 8404-1300
(11) 3055-2060
On 5/11/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
On 5/11/07, Alastair Maw <[EMAIL PROTECTED]> wrote:
> Eelco Hillenius wrote:
> > Cheers. I'd also like to pull in what you proposed in another thread,
> > which is to introduce a more generic hook. E.g.
> >
> > public interface IValidationBindListener {
> >
> > void onAdded(Component component);
> >
> > void onRemoved(Component component);
> > }
> >
> > It would still need to be a separate interface to avoid tight coupling
> > between validators and components (as we like validators to be useful
> > outside of Wicket as well at some point).
>
> Yeah. I like that.
>
> I'd call it onAdd() and onRemove(), to keep things consistent (we use
> onAttach, not onAttached(), etc.). But this is what gets my vote.
>
> The only thing we'd have to think about would be removing behaviours
> when you remove the validator. We can let the validator worry about this
> with the onRemove() hook, obviously.
>
> The only slight issue with that is singleton behaviours that are used in
> multiple validators. If you add two validators which both add the same
> behaviour, then when you remove one of them, this behaviour will be
> removed. Maybe we need reference counting on that, so if the same
> instance of a behaviour is added twice, it still all works properly when
> you remove it once. ;-)
Yeah. Same thing goes for the same (singleton) behaviors added as
normal behaviors and later on as validators.
Note that at this stage we don't even support removing validators.
Maybe we shouldn't to start with, as honestly, while it would make the
API more complete, I can't realy think of good use cases.
Eelco
