Along the same lines (and still as part of a dynamic form), is it possible to remove AttributeModifiers? I'd like a TextField component to be disabled or enabled depending on a RadioChoice selection, removing the "disabled" attribute modifier in the RadioChoice#onSelectionChanged method. I don't think #removeAllAttributeModifiers is appropriate here--since attribute modifiers already come with names, should be pretty easy to support something like ... public void removeAttribute(String attrName) ... in Component. Is there any reason *not* to expose such a method? -- Roan ________________________________
From: [EMAIL PROTECTED] on behalf of Johan Compagner
Sent: Wed 4/26/2006 10:55 AM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] RE: Removing a Validator
removeAll can be added, i don't care to much except that we then must take care
of back button also so that has to be versioned.
johan
On 4/26/06, Roan O'Sullivan <[EMAIL PROTECTED]> wrote:
This is certainly a better workaround than re-instantiating the
component... thanks.
But I'm still curious, is there any reason you would *not* want to add
a #removeAllValidators() method to FormComponent? I really don't see how it
would add any complexity/ambiguity.
Thanks, Roan
________________________________
From: [EMAIL PROTECTED] on behalf of Johan Compagner
Sent: Tue 4/25/2006 5:34 PM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] RE: Removing a Validator
MyCompoundValidator compound = new MyCompoundValidatior();
compound.add(XXXValidatior);
compound.add(YYYValidator);
compound.validate()
{
iterator.next().validate()
}
component.add(compound);
compound.remove(xxx);
johan
On 4/25/06, Roan O'Sullivan <[EMAIL PROTECTED] > wrote:
Hi Igor,
I have this same requirement, also in the context of dynamic
forms.
I think a simple #removeAllValidators() would do the trick
without introducing ambiguity or any additional complexity. In v1.1.1 I end up
reconstructing the component when, for example, I need to remove a
TypeValidator. This can be a real pain.
Haven't had a chance to check out IFormValidator, and it may do
what I require. However, I don't see how a #removeAllValidators() could hurt
either :).
Thanks,
Roan
________________________________
From: [EMAIL PROTECTED] on behalf of Igor Vaynberg
Sent: Tue 4/25/2006 2:09 PM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] RE: Removing a Validator
but once you introduce the map you introduce the ambiguity of
evaluation order as well and it makes things more complex to manage.
also once you allow removal you alse need to allow insertion.
it keeps getting messier and messier for the end user.
you can also potentially do what you want by overriding
isrequired(), but you cannot then use the model of the component it depends on,
only its input value.
i think a IFormValidator which delegates to a few IValidator is
the cleanest way to go, but thats just my two cents.
-Igor
On 4/25/06, Andrew Strickland < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> > wrote:
My first thought was the component would have a Map of
validators that you store by a validator name...that way you could add or
remove like remove( IValidator.getName () )...also that way you could never end
up with more than one of the same type of Validator on any given component.
Andy
>How would you remove the validator? Would you do it by
index or by instance?
>Its not very clean either way. Check out
IFormValidator, I think it fits
>your usecase better then an IValidator.
>-Igor
On 4/25/06, Andrew Strickland < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> > wrote:
>
> Was the capability added in 1.2 to remove Validators
from a component? I=
f
> not, are there any plans to add such a capability?
>
> When doing dynamic forms it is a huge convenience to
be able to add and
> remove validators based on a user selection on
another field in the form.
>
> An example: on my project some fields are required or
not depending on th=
e
> classification of the system. During account
creation the user has the
> ability to choose which classification they are
requesting their account =
be
> created for. If they choose the more restrictive
classification and then
> change their mind and switch to the less restrictive
some of the fields t=
hat
> I added a validator to will now STILL have the
RequiredValidator even tho=
ugh
> it is no longer a required field, and I have no way
of removing the
> validator.
>
> Andy
<<winmail.dat>>
