Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
+1 for option 2 [for wicket 1.5] --- Inaiat Henrique On Mon, Apr 11, 2011 at 6:25 AM, Andrea Del Bene wrote: > Sorry, I know I'm little late but I'd like to vote for the 2nd option > > This has been discussed before >> (https://issues.apache.org/jira/browse/WICKET-1221), but I can't find >> the old vote thread to see what folks think. The problem is that a >> checkbox is a weird bird when it comes to HTTP. If it's unchecked, it >> doesn't send a value which makes Wicket think you haven't provided a >> value for that input field. Right now, if you call setRequired(true) >> on a CheckBox, it's going to require the user to actually check the >> box. What do folks think the desired behavior should be? >> >> 1. The current approach is correct, requiring a checkbox means >> requiring that it be checked. >> >> 2. A checkbox shouldn't be able to be required. You can't *not* >> provide a value (it's binary) for a checkbox, so therefore it always >> should satisfy the required requirement. >> >> - >> 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 > >
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
Sorry, I know I'm little late but I'd like to vote for the 2nd option This has been discussed before (https://issues.apache.org/jira/browse/WICKET-1221), but I can't find the old vote thread to see what folks think. The problem is that a checkbox is a weird bird when it comes to HTTP. If it's unchecked, it doesn't send a value which makes Wicket think you haven't provided a value for that input field. Right now, if you call setRequired(true) on a CheckBox, it's going to require the user to actually check the box. What do folks think the desired behavior should be? 1. The current approach is correct, requiring a checkbox means requiring that it be checked. 2. A checkbox shouldn't be able to be required. You can't *not* provide a value (it's binary) for a checkbox, so therefore it always should satisfy the required requirement. - 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
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
On 06/04/2011 16:53, James Carman wrote: As the voting stands right now, it looks like option 2 is the winner (I counted Matthew as +1 for option 1 even though he didn't really cast a vote, but his response indicated support for option 1): I was convinced by Igor's comments to change my mind if that helps at all (vote for option 2). But it's a pretty busy mailing list and I felt if I posted just to say "Having thought about it, I now agree with eveyrone who is arguing for consistency of framework" that would be unhelpful. I was hoping to just keep quiet and avoid drawing any more attention to the imbalance between the size of my ego and the size of my experience with Wicket. ;) Matt - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
+1 for 2nd option -Original Message- From: Igor Vaynberg Date: Tue, 5 Apr 2011 11:46:40 To: Reply-To: users@wicket.apache.org Subject: Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true) +1 for option 2 -igor On Fri, Apr 1, 2011 at 10:34 AM, James Carman wrote: > This has been discussed before > (https://issues.apache.org/jira/browse/WICKET-1221), but I can't find > the old vote thread to see what folks think. The problem is that a > checkbox is a weird bird when it comes to HTTP. If it's unchecked, it > doesn't send a value which makes Wicket think you haven't provided a > value for that input field. Right now, if you call setRequired(true) > on a CheckBox, it's going to require the user to actually check the > box. What do folks think the desired behavior should be? > > 1. The current approach is correct, requiring a checkbox means > requiring that it be checked. > > 2. A checkbox shouldn't be able to be required. You can't *not* > provide a value (it's binary) for a checkbox, so therefore it always > should satisfy the required requirement. > > - > 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
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
As the voting stands right now, it looks like option 2 is the winner (I counted Matthew as +1 for option 1 even though he didn't really cast a vote, but his response indicated support for option 1): Option 1: 4 +1s Option 2: 6 +1s This isn't an "official" vote, per se, but it is an informative poll that will help the core developers figure out what the heck to do with this issue. Thanks for all who voted! On Fri, Apr 1, 2011 at 1:34 PM, James Carman wrote: > This has been discussed before > (https://issues.apache.org/jira/browse/WICKET-1221), but I can't find > the old vote thread to see what folks think. The problem is that a > checkbox is a weird bird when it comes to HTTP. If it's unchecked, it > doesn't send a value which makes Wicket think you haven't provided a > value for that input field. Right now, if you call setRequired(true) > on a CheckBox, it's going to require the user to actually check the > box. What do folks think the desired behavior should be? > > 1. The current approach is correct, requiring a checkbox means > requiring that it be checked. > > 2. A checkbox shouldn't be able to be required. You can't *not* > provide a value (it's binary) for a checkbox, so therefore it always > should satisfy the required requirement. > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
+1 for option 2 -igor On Fri, Apr 1, 2011 at 10:34 AM, James Carman wrote: > This has been discussed before > (https://issues.apache.org/jira/browse/WICKET-1221), but I can't find > the old vote thread to see what folks think. The problem is that a > checkbox is a weird bird when it comes to HTTP. If it's unchecked, it > doesn't send a value which makes Wicket think you haven't provided a > value for that input field. Right now, if you call setRequired(true) > on a CheckBox, it's going to require the user to actually check the > box. What do folks think the desired behavior should be? > > 1. The current approach is correct, requiring a checkbox means > requiring that it be checked. > > 2. A checkbox shouldn't be able to be required. You can't *not* > provide a value (it's binary) for a checkbox, so therefore it always > should satisfy the required requirement. > > - > 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
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
Hi, As the guy who started that old thread and the old vote, I vote +1 for (2). -- Kent Tong Useful news for network admins at http://www2.cpttm.org.mo/cyberlab/netadmin-news - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
By "nature of checkbox" you mean nature of HTTP. As setRequired is Wicket API, IMO it should abstract the empty info about false input from framework users, in benefit of those who are deliberately sending a 'false' value in their form input. On Sat, Apr 2, 2011 at 12:30 PM, Bruno Borges wrote: > No problem. :-) > > setRequired means what you said: "please, provide a value". > > In case of a Checkbox, if setRequired is false, it means: "you don't have > to > provide a value" which in other words means "you have the choice to do > nothing about it" which in other words means "you don't have to check it". > Which by the nature of a checkbox, means 'false'. Now, if setRequired true, > then it means "you have to provide a value" which means "you don't have the > choice to ignore it" wich means "you must check it", which by the nature of > the checkbox, means 'true'. > > Now, if setRequired of checkboxes happens to do nothing (at the worse > throws > an UnsupportedException; but I think setRequired is final), then it would > break *a lot* of things. Even if you state that this change is only 1.5 and > people should migrate... that is complicate. > > I'm deploying Wicket for a huge healthcare/life/auto ensurance company in > Brazil, and I'm sure they won't like the idea of having to migrate 300 apps > to 1.5, with this kind of API change. Until now, most of the changes can be > fixed (from 1.4 to 1.5) in a higher level, not having to look at every and > single Form. With this, it would be a nightmare. > > just my 2 cents > > > Bruno Borges > www.brunoborges.com.br > +55 21 76727099 > > "The glory of great men should always be > measured by the means they have used to > acquire it." > - Francois de La Rochefoucauld > > > > On Sat, Apr 2, 2011 at 5:47 AM, Maarten Billemont > wrote: > > > > > On 02 Apr 2011, at 01:01, Maarten Billemont wrote: > > > > > > > > On 02 Apr 2011, at 00:13, Bruno Borges wrote: > > > > > >> [] Please, check this box if you agree with EULA > > >> [ x ] Please, uncheck this box if you don't want to receive > > notifications > > >> > > >> > > >> In this case, I would set the first checkbox as required, and leave > the > > >> later as optional. > > >> > > >> Vote for (1) +1 > > > > > > Please don't pretend a checkbox is a Radio component. This is > irrelevant > > to this discussion. > > > > I totally missed that you have two different questions here, apologies. > > > > Nevertheless, you're disregarding my earlier statements. You're asking > us > > to make "setRequired" do something that's completely different from what > > it's supposed to do. If you require a certain value, that's what > validators > > are for. If you require a value to be given, you use setRequired. > > Checkboxes ALWAYS give a value. There is no "I choose not to choose" > > option with a checkbox. That is what setRequired is for. It forces you > to > > make a *choice*. It does not force you to make a specific choice. > > - > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > -- Pedro Henrique Oliveira dos Santos
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
No problem. :-) setRequired means what you said: "please, provide a value". In case of a Checkbox, if setRequired is false, it means: "you don't have to provide a value" which in other words means "you have the choice to do nothing about it" which in other words means "you don't have to check it". Which by the nature of a checkbox, means 'false'. Now, if setRequired true, then it means "you have to provide a value" which means "you don't have the choice to ignore it" wich means "you must check it", which by the nature of the checkbox, means 'true'. Now, if setRequired of checkboxes happens to do nothing (at the worse throws an UnsupportedException; but I think setRequired is final), then it would break *a lot* of things. Even if you state that this change is only 1.5 and people should migrate... that is complicate. I'm deploying Wicket for a huge healthcare/life/auto ensurance company in Brazil, and I'm sure they won't like the idea of having to migrate 300 apps to 1.5, with this kind of API change. Until now, most of the changes can be fixed (from 1.4 to 1.5) in a higher level, not having to look at every and single Form. With this, it would be a nightmare. just my 2 cents Bruno Borges www.brunoborges.com.br +55 21 76727099 "The glory of great men should always be measured by the means they have used to acquire it." - Francois de La Rochefoucauld On Sat, Apr 2, 2011 at 5:47 AM, Maarten Billemont wrote: > > On 02 Apr 2011, at 01:01, Maarten Billemont wrote: > > > > > On 02 Apr 2011, at 00:13, Bruno Borges wrote: > > > >> [] Please, check this box if you agree with EULA > >> [ x ] Please, uncheck this box if you don't want to receive > notifications > >> > >> > >> In this case, I would set the first checkbox as required, and leave the > >> later as optional. > >> > >> Vote for (1) +1 > > > > Please don't pretend a checkbox is a Radio component. This is irrelevant > to this discussion. > > I totally missed that you have two different questions here, apologies. > > Nevertheless, you're disregarding my earlier statements. You're asking us > to make "setRequired" do something that's completely different from what > it's supposed to do. If you require a certain value, that's what validators > are for. If you require a value to be given, you use setRequired. > Checkboxes ALWAYS give a value. There is no "I choose not to choose" > option with a checkbox. That is what setRequired is for. It forces you to > make a *choice*. It does not force you to make a specific choice. > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
On 02 Apr 2011, at 01:01, Maarten Billemont wrote: > > On 02 Apr 2011, at 00:13, Bruno Borges wrote: > >> [] Please, check this box if you agree with EULA >> [ x ] Please, uncheck this box if you don't want to receive notifications >> >> >> In this case, I would set the first checkbox as required, and leave the >> later as optional. >> >> Vote for (1) +1 > > Please don't pretend a checkbox is a Radio component. This is irrelevant to > this discussion. I totally missed that you have two different questions here, apologies. Nevertheless, you're disregarding my earlier statements. You're asking us to make "setRequired" do something that's completely different from what it's supposed to do. If you require a certain value, that's what validators are for. If you require a value to be given, you use setRequired. Checkboxes ALWAYS give a value. There is no "I choose not to choose" option with a checkbox. That is what setRequired is for. It forces you to make a *choice*. It does not force you to make a specific choice. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
>> On 02 Apr 2011, at 00:13, Bruno Borges wrote: >> >> [ ] Please, check this box if you agree with EULA >> [ x ] Please, uncheck this box if you don't want to receive notifications >> >> >> In this case, I would set the first checkbox as required, and leave the >> later as optional. >> >> Vote for (1) +1 >On Fri, Apr 1, 2011 at 5:01 PM, Maarten Billemont wrote: > > Please don't pretend a checkbox is a Radio component. This is irrelevant to > this discussion. > I don't see how radio choices could represent these options as elegantly as checkboxes. It seems you would need four radio choices, two for each selection, possibly each pair in a radio group. With respect to the larger discussion, I don't think it matters. If you wish to setRequired(true) on a checkbox, it means it must be checked. If we're not allowed to setRequired(), then a validator can require checked. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
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: 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
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
On 02 Apr 2011, at 00:13, Bruno Borges wrote:
> [] Please, check this box if you agree with EULA
> [ x ] Please, uncheck this box if you don't want to receive notifications
>
>
> In this case, I would set the first checkbox as required, and leave the
> later as optional.
>
> Vote for (1) +1
Please don't pretend a checkbox is a Radio component. This is irrelevant to
this discussion.
>
> Best regards,
>
> Bruno Borges
> www.brunoborges.com.br
> +55 21 76727099
>
> "The glory of great men should always be
> measured by the means they have used to
> acquire it."
> - Francois de La Rochefoucauld
>
>
>
> On Fri, Apr 1, 2011 at 6:46 PM, Maarten Billemont wrote:
>
>>
>> On 01 Apr 2011, at 20:56, Daniel Neugebauer wrote:
>>
>>> 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 don't see why you would think that. setRequired(true) means, "You must
>> provide a value for this component's model". An empty String and a null
>> String mean the same thing (since you cannot input a null String); in both
>> instances, it's the user saying: "I have no value for this". Hence, it
>> makes perfect sense that the setRequired(true) fails validation on an empty
>> text field.
>>
>> Contrary to a text field, an unchecked checkbox does not mean: "no value".
>> It means: "Off". As though I'd write "false" in my text field.
>>
>> If the web application asks me whether I want to gift-wrap my purchase,
>> leaving the box unchecked does not mean I can't or don't want to make up my
>> mind. It means I do not want it gift wrapped. It's me saying: "No."
>>
>>> 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(this,
>> "test1"));
>>> tf1.setRequired(true);
>>> tf1.setConvertEmptyInputStringToNull(false);
>>> form.add(tf1);
>>>
>>> TextField tf2 = new TextField("text2", new PropertyModel(this,
>> "test2"));
>>> tf2.setRequired(true);
>>> tf2.setConvertEmptyInputStringToNull(true);
>>> form.add(tf2);
>>>
>>
>> Regardless, setConvertEmptyInputStringToNull is not relevant during
>> checkRequired. It is only used by the developer to say, if the user doesn't
>> enter any characters, make my model object null instead of an empty string.
>> checkRequired checks Strings.isEmpty(), which is perfectly sensible (ref.
>> the first paragraph of this email).
>> -
>> 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
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
[] Please, check this box if you agree with EULA
[ x ] Please, uncheck this box if you don't want to receive notifications
In this case, I would set the first checkbox as required, and leave the
later as optional.
Vote for (1) +1
Best regards,
Bruno Borges
www.brunoborges.com.br
+55 21 76727099
"The glory of great men should always be
measured by the means they have used to
acquire it."
- Francois de La Rochefoucauld
On Fri, Apr 1, 2011 at 6:46 PM, Maarten Billemont wrote:
>
> On 01 Apr 2011, at 20:56, Daniel Neugebauer wrote:
>
> > 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 don't see why you would think that. setRequired(true) means, "You must
> provide a value for this component's model". An empty String and a null
> String mean the same thing (since you cannot input a null String); in both
> instances, it's the user saying: "I have no value for this". Hence, it
> makes perfect sense that the setRequired(true) fails validation on an empty
> text field.
>
> Contrary to a text field, an unchecked checkbox does not mean: "no value".
> It means: "Off". As though I'd write "false" in my text field.
>
> If the web application asks me whether I want to gift-wrap my purchase,
> leaving the box unchecked does not mean I can't or don't want to make up my
> mind. It means I do not want it gift wrapped. It's me saying: "No."
>
> > 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(this,
> "test1"));
> >tf1.setRequired(true);
> >tf1.setConvertEmptyInputStringToNull(false);
> >form.add(tf1);
> >
> >TextField tf2 = new TextField("text2", new PropertyModel(this,
> "test2"));
> >tf2.setRequired(true);
> >tf2.setConvertEmptyInputStringToNull(true);
> >form.add(tf2);
> >
>
> Regardless, setConvertEmptyInputStringToNull is not relevant during
> checkRequired. It is only used by the developer to say, if the user doesn't
> enter any characters, make my model object null instead of an empty string.
> checkRequired checks Strings.isEmpty(), which is perfectly sensible (ref.
> the first paragraph of this email).
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
On 01 Apr 2011, at 20:56, Daniel Neugebauer wrote:
> 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 don't see why you would think that. setRequired(true) means, "You must
provide a value for this component's model". An empty String and a null String
mean the same thing (since you cannot input a null String); in both instances,
it's the user saying: "I have no value for this". Hence, it makes perfect
sense that the setRequired(true) fails validation on an empty text field.
Contrary to a text field, an unchecked checkbox does not mean: "no value". It
means: "Off". As though I'd write "false" in my text field.
If the web application asks me whether I want to gift-wrap my purchase, leaving
the box unchecked does not mean I can't or don't want to make up my mind. It
means I do not want it gift wrapped. It's me saying: "No."
> 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(this,
> "test1"));
>tf1.setRequired(true);
>tf1.setConvertEmptyInputStringToNull(false);
>form.add(tf1);
>
>TextField tf2 = new TextField("text2", new PropertyModel(this,
> "test2"));
>tf2.setRequired(true);
>tf2.setConvertEmptyInputStringToNull(true);
>form.add(tf2);
>
Regardless, setConvertEmptyInputStringToNull is not relevant during
checkRequired. It is only used by the developer to say, if the user doesn't
enter any characters, make my model object null instead of an empty string.
checkRequired checks Strings.isEmpty(), which is perfectly sensible (ref. the
first paragraph of this email).
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
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 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
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
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
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
I second Daniel's comments.
+1 for option 1
From: Daniel Neugebauer
To: users@wicket.apache.org
Date: 04/01/2011 02:56 PM
Subject:Re: [VOTE] Behavior of CheckBox With Respect to
setRequired(true)
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(this, "test1"));
tf1.setRequired(true);
tf1.setConvertEmptyInputStringToNull(false);
form.add(tf1);
TextField tf2 = new TextField("text2", new
PropertyModel(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: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Notice: This communication, including any attachments, is intended solely
for the use of the individual or entity to which it is addressed. This
communication may contain information that is protected from disclosure
under State and/or Federal law. Please notify the sender immediately if
you have received this communication in error and delete this email from
your system. If you are not the intended recipient, you are requested not
to disclose, copy, distribute or take any action in reliance on the
contents of this information.
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
On Fri, Apr 1, 2011 at 2:33 PM, Matthew Pennington wrote: > > (1) > > I can't think of any useful benefit to (2) but I *can* think of a very > useful benefit for (1) The classic "tick this box to indicate that you have > read and agreed to sell us your soul EULA would be the obvious time to use > a checkbox and setRequired(true) if it worked as per (1). > The way I found it was that Wicketopia automatically marks every primitive property as required, since primitive fields can't be null. When you use a checkbox as the "editor", it messes up, because the user is required to check those checkboxes. I have worked around it, but it just seems inconsistent with the way everything else works in Wicket. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
no, validators do not typically handle "null" values. those are controlled by the required flag. the reason checkboxes are unique is that they have no "null" value, a null in the checkbox means "false" -igor On Fri, Apr 1, 2011 at 11:57 AM, Matthew Pennington wrote: > On 01/04/2011 19:34, Igor Vaynberg wrote: >> >> that can be accomplished using a validator. > > Is that not true of all form components? > > Matt >> >> -igor >> >> >> On Fri, Apr 1, 2011 at 11:33 AM, Matthew Pennington >> wrote: 1. The current approach is correct, requiring a checkbox means requiring that it be checked. 2. A checkbox shouldn't be able to be required. You can't *not* provide a value (it's binary) for a checkbox, so therefore it always should satisfy the required requirement. >>> >>> (1) >>> >>> I can't think of any useful benefit to (2) but I *can* think of a very >>> useful benefit for (1) The classic "tick this box to indicate that you >>> have >>> read and agreed to sell us your soul EULA would be the obvious time to >>> use >>> a checkbox and setRequired(true) if it worked as per (1). >>> >>> >>> - >>> 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 >> >> >> > > > - > 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
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
On 01/04/2011 19:34, Igor Vaynberg wrote: that can be accomplished using a validator. Is that not true of all form components? Matt -igor On Fri, Apr 1, 2011 at 11:33 AM, Matthew Pennington wrote: 1. The current approach is correct, requiring a checkbox means requiring that it be checked. 2. A checkbox shouldn't be able to be required. You can't *not* provide a value (it's binary) for a checkbox, so therefore it always should satisfy the required requirement. (1) I can't think of any useful benefit to (2) but I *can* think of a very useful benefit for (1) The classic "tick this box to indicate that you have read and agreed to sell us your soul EULA would be the obvious time to use a checkbox and setRequired(true) if it worked as per (1). - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
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(this, "test1"));
tf1.setRequired(true);
tf1.setConvertEmptyInputStringToNull(false);
form.add(tf1);
TextField tf2 = new TextField("text2", new
PropertyModel(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: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
that can be accomplished using a validator. -igor On Fri, Apr 1, 2011 at 11:33 AM, Matthew Pennington wrote: > >> 1. The current approach is correct, requiring a checkbox means >> requiring that it be checked. >> >> 2. A checkbox shouldn't be able to be required. You can't *not* >> provide a value (it's binary) for a checkbox, so therefore it always >> should satisfy the required requirement. > > (1) > > I can't think of any useful benefit to (2) but I *can* think of a very > useful benefit for (1) The classic "tick this box to indicate that you have > read and agreed to sell us your soul EULA would be the obvious time to use > a checkbox and setRequired(true) if it worked as per (1). > > > - > 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
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
1. The current approach is correct, requiring a checkbox means requiring that it be checked. 2. A checkbox shouldn't be able to be required. You can't *not* provide a value (it's binary) for a checkbox, so therefore it always should satisfy the required requirement. (1) I can't think of any useful benefit to (2) but I *can* think of a very useful benefit for (1) The classic "tick this box to indicate that you have read and agreed to sell us your soul EULA would be the obvious time to use a checkbox and setRequired(true) if it worked as per (1). - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
I vote for 2, checkbox needs always to satisfy the required requirement. As pointed, there are no parameter in the HTTP request reader for false inputs, we can't distinguish 'false' from 'null', so we can't consider that user isn't meeting the required condition. On Fri, Apr 1, 2011 at 2:34 PM, James Carman wrote: > This has been discussed before > (https://issues.apache.org/jira/browse/WICKET-1221), but I can't find > the old vote thread to see what folks think. The problem is that a > checkbox is a weird bird when it comes to HTTP. If it's unchecked, it > doesn't send a value which makes Wicket think you haven't provided a > value for that input field. Right now, if you call setRequired(true) > on a CheckBox, it's going to require the user to actually check the > box. What do folks think the desired behavior should be? > > 1. The current approach is correct, requiring a checkbox means > requiring that it be checked. > > 2. A checkbox shouldn't be able to be required. You can't *not* > provide a value (it's binary) for a checkbox, so therefore it always > should satisfy the required requirement. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Pedro Henrique Oliveira dos Santos
[VOTE] Behavior of CheckBox With Respect to setRequired(true)
This has been discussed before (https://issues.apache.org/jira/browse/WICKET-1221), but I can't find the old vote thread to see what folks think. The problem is that a checkbox is a weird bird when it comes to HTTP. If it's unchecked, it doesn't send a value which makes Wicket think you haven't provided a value for that input field. Right now, if you call setRequired(true) on a CheckBox, it's going to require the user to actually check the box. What do folks think the desired behavior should be? 1. The current approach is correct, requiring a checkbox means requiring that it be checked. 2. A checkbox shouldn't be able to be required. You can't *not* provide a value (it's binary) for a checkbox, so therefore it always should satisfy the required requirement. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
