the equal password validator is there because it is such a common usecase. does anyone else want it removed? i also dont really see the point, i guess i shouldve never checked it in.
if you want to specify the key in the constructor you can create a subclass that does that
if you use formcomponent.setlabel then you shouldnt need to even subclass equal validator for the resource key because the key can be generic: ${label1} must have the same value as ${label2}
for passwords it usually differs so i guess it is nice to have a subclass that has a different key.
-Igor
On 5/8/06, Bruno Borges <
[EMAIL PROTECTED]> wrote:
Besides the bug of having those two components not Serializable (which throws an Exception while trying to bind them to HttpSession automatically by Wicket), how about make EqualPasswordInputValidator a subclass of EqualInputValidator? There's only one difference: the key of the message to be displayed.
Anyway... why there's a EqualPasswordInputValidator?! This way, there should be EqualLoginInputValidator, EqualBirthdayInputValidator, etc... :)
if the developer wants to put more than one EqualInputValidator in the same form, he/she could specify the Key of the message in the constructor.
FormInput.properties -->
inputForm.SomeUserKey.EqualInputValidator=bla bla bla...
FormInput.java -->
add(new EqualInputValidator(formComponentLeft, formComponentRight, "SomeUserKey"));
Regardsm
--
Bruno Borges
[EMAIL PROTECTED]
Sun Certified Java Programmer for 1.4
Sun Certified Web Component Developer for 1.4
