to clarify, this kind of change is off the table for 1.4, but may be implemented in 1.5
-igor On Fri, Apr 1, 2011 at 2:23 PM, Maarten Billemont <lhun...@gmail.com> 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: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
