I would stick with 1 (required to be checked).
The main reason would be not to break compatibility with old versions. I
actually used .setRequired(true) on legal checkboxes (disclaimers) in
one of our applications because if I have a "required checkbox" I expect
it to be needed to be checked. Although I will change that in our
project now that I know such a change is being discussed, I wouldn't
expect others to be that observant of the issue and have unit tests that
prevent anything from breaking on a future upgrade.
BTW an empty string (that's not null) is a string nevertheless.
Following the argument that an unchecked (false) checkbox should be
regarded as valid if it is required, an empty string should be accepted
as a valid input as well. I've just tested it with Wicket 1.4 and
actually both of the following TextFields validate to a failed state:
TextField tf1 = new TextField("text1", new
PropertyModel<String>(this, "test1"));
tf1.setRequired(true);
tf1.setConvertEmptyInputStringToNull(false);
form.add(tf1);
TextField tf2 = new TextField("text2", new
PropertyModel<String>(this, "test2"));
tf2.setRequired(true);
tf2.setConvertEmptyInputStringToNull(true);
form.add(tf2);
So, TextField.setRequired doesn't validate the syntactic meaning as
well, instead it validates the semantic meaning, just as
CheckBox.setRequired does. If that's consistently used throughout
Wicket, I would expect CheckBox.setRequired to validate false unless the
CheckBox is actually checked.
Just my 2 cents,
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
