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: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
