I agree with Maarten, +1 for the second behaviour (2) and let validators
do the rest.
--
Marek
On 04/01/2011 11:23 PM, Maarten Billemont wrote:
On 01 Apr 2011, at 20:56, Daniel Neugebauer wrote:
I would stick with 1 (required to be checked).
The main reason would be not to break compatibility with old versions.
Lame reason. "Don't fix bugged behavior because old code relies on it."
All that got us is a renders-well-in-IE 6.0 web, which we only barely are
struggling out of with the advent of Mozilla et al. who decided to do the right
thing for a change.
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.
Get the context right. "You are required to provide a value" is not the same as "You are
required to provide this specific value". The context of the term "required" in the
setRequired method refers to the former, not the latter. As Igor pointed out, the latter is accomplished
with a validator. setRequired has no business looking at what your value is, just whether or not one exists.
Changing that context for one component for whatever reason breaks the
consistency and reliability of the API.
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.
I hope people test their web apps before they deploy a new release to
production. I'm sure they'll notice the change if they do.
I vote (2) +1, if it doesn't make sense to apply setRequired to a certain type
of component because the HTML model simply does not permit it, giving
setRequired a different meaning is not an acceptable alternative.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
