You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by James Carman <ja...@carmanconsulting.com> on 2011/04/01 19:34:54 UTC
[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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
Posted by Pedro Santos <pe...@gmail.com>.
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 <ja...@carmanconsulting.com>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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Pedro Henrique Oliveira dos Santos
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
Posted by Henrique <in...@gmail.com>.
+1 for option 2 [for wicket 1.5]
---
Inaiat Henrique
On Mon, Apr 11, 2011 at 6:25 AM, Andrea Del Bene <ad...@ciseonweb.it>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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
Posted by Andrea Del Bene <ad...@ciseonweb.it>.
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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <lh...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
Posted by Marek Šabo <ms...@buk.cvut.cz>.
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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
Posted by Maarten Billemont <lh...@gmail.com>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
Posted by MZ...@osc.state.ny.us.
I second Daniel's comments.
+1 for option 1
From: Daniel Neugebauer <ma...@energiequant.de>
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<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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@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)
Posted by Daniel Neugebauer <ma...@energiequant.de>.
On 04/03/2011 07:58 AM, Maarten Billemont wrote:
> If you consider every single instance where people fuck up and leave "compatibility" for code that relies on a bug to exists in your framework, then not only do you force all new Wicket users to learn about all the bugs, instead of just using their intuition, but you also end up with a patch-job framework.
The issue in JIRA has been created in late 2007, now we have 2011. It
does seem to me like not many people worried about that either way (but
I too haven't seen the old vote/discussion about it). This time, 10
people on this list have an opinion about it, others haven't replied yet.
As with my first reply, I would expect a framework to behave
consistently and if the behaviour of CheckBox.setRequired doesn't match
that general behaviour of all other components, then there may be a
reason to fix it (otherwise it's not broken). But you may want to
evaluate if that (currently) minor change is worth its unexpected effects.
Since JavaDoc doesn't say much about what setRequired is supposed to do
and a "required checkbox" in spoken language means "you have to check
that box to continue", I would at least expect a _framework_ to roll out
such a fundamental change slowly if it is being done. Such as issuing a
warning starting with 1.5 each time .setRequired is called (the first
time) on a CheckBox while maintaining the original behaviour. With 1.6
or 1.7 it can then be switched to the new behaviour and finally silenced
again. Usually that would be a case for @deprecated but since
setRequired is inherited from a super component that shouldn't be possible?
Maybe throwing an Exception would be best to remove that behaviour as
smoothly as possible, thus developers are forced to take a look at their
code and remove calls to setRequired (or set it to false which is the
same). I think there should at least be an explanation of the expected
behaviour on JavaDoc.
Why call setRequired on a CheckBox anyway? With the discussed new
behaviour there's no need to ever call it, since it will always behave
the same way and succeed on validation. So if the old behaviour is
removed, it would be the same as to never calling CheckBox.setRequired
in the first place.
Is there any real world reason why to change it? The only thing I can
think about is some method that runs on any FormComponents and calls
setRequired(true) on them regardless of their specific subclasses while
expecting the "validates if there is any value not null" behaviour
(which in turn still wouldn't accept empty strings which should be a
valid input if I set convertEmptyInputStringToNull(false)). The specific
implementation of TextField.checkRequired doesn't matter in that case
since it could be open to a change to match a consistent behaviour as
well and convertEmptyInputStringToNull would make sense to be not
ignored on that check considering the argumentation for the new CheckBox
behaviour. As Igor replied farther above, checkRequired should check for
null values. That convertEmptyInputStringToNull happens to take effect
after (?) checkRequired may not be very conformant to the expected
general behaviour as well:
Quote from Igor Vaynberg to Matthew Pennington: (1 Apr 2011, 21:07)
no, validators do not typically handle "null" values. those are
controlled by the required flag.
However, such a change would break even more things.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
Posted by Maarten Billemont <lh...@gmail.com>.
On 02 Apr 2011, at 17:30, 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"
This is where you go wrong. If I have a text field with a Model.of("moo") and the user "does nothing about it", then the field won't trigger on setRequired(true) either. Because it has a value. The only difference here is that HTML forces the user to submit a value, not allowing him to not choose. In that sense, it's like so many things in life, you may not want to choose, but if you don't life chooses for you. You don't have the luxury of saying, "I pass". A checkbox [ ] Male, doesn't give you the option of saying you don't want to divulge your gender.
> 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"
And here. "You don't have the choice to ignore it", by nature of a checkbox means: "You have to either say "Yes", or "No", to this option. [ ] Male, is me saying, "No", I'm not male. Not "I ignore this question".
> 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.
For heaven's sake, have a backbone. People make mistakes. People fuck up. Deal with it. If you consider every single instance where people fuck up and leave "compatibility" for code that relies on a bug to exists in your framework, then not only do you force all new Wicket users to learn about all the bugs, instead of just using their intuition, but you also end up with a patch-job framework.
What do you do when you have a bug in your own code? Shrug it off and teach users about the bugs so they can dodge them? No. You fix it. And you have a whole lot of work upgrading all your dependents. We call that responsibility. And in this instance, Wicket devs need to assume their responsibility and face the wrath of lots of developers that will think bugs in the framework are acceptable so long as it will save them some work and a talk with their boss.
> 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 <lh...@gmail.com> 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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
Posted by Pedro Santos <pe...@gmail.com>.
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 <br...@gmail.com>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 <lh...@gmail.com>
> 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-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
--
Pedro Henrique Oliveira dos Santos
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
Posted by Bruno Borges <br...@gmail.com>.
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 <lh...@gmail.com> 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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
Posted by Maarten Billemont <lh...@gmail.com>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
Posted by gnul <nu...@gmail.com>.
>> 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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
Posted by Maarten Billemont <lh...@gmail.com>.
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 <lh...@gmail.com> 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<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);
>>>
>>
>> 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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
Posted by Bruno Borges <br...@gmail.com>.
[ ] 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 <lh...@gmail.com> 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<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);
> >
>
> 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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
Posted by Maarten Billemont <lh...@gmail.com>.
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<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);
>
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
Posted by Daniel Neugebauer <ma...@energiequant.de>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
Posted by James Carman <ja...@carmanconsulting.com>.
On Fri, Apr 1, 2011 at 2:33 PM, Matthew Pennington
<ma...@profounddecisions.co.uk> 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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
Posted by Igor Vaynberg <ig...@gmail.com>.
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
<ma...@profounddecisions.co.uk> 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
>> <ma...@profounddecisions.co.uk> 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-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
Posted by Matthew Pennington <ma...@profounddecisions.co.uk>.
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
> <ma...@profounddecisions.co.uk> 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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
Posted by Igor Vaynberg <ig...@gmail.com>.
that can be accomplished using a validator.
-igor
On Fri, Apr 1, 2011 at 11:33 AM, Matthew Pennington
<ma...@profounddecisions.co.uk> 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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
Posted by Matthew Pennington <ma...@profounddecisions.co.uk>.
> 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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
Posted by mb...@gmail.com.
+1 for 2nd option
-----Original Message-----
From: Igor Vaynberg <ig...@gmail.com>
Date: Tue, 5 Apr 2011 11:46:40
To: <us...@wicket.apache.org>
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
<ja...@carmanconsulting.com> 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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
Posted by Igor Vaynberg <ig...@gmail.com>.
+1 for option 2
-igor
On Fri, Apr 1, 2011 at 10:34 AM, James Carman
<ja...@carmanconsulting.com> 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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
Posted by Matthew Pennington <ma...@profounddecisions.co.uk>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
Posted by James Carman <ja...@carmanconsulting.com>.
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 <ja...@carmanconsulting.com> 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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org