Create Documentation about removing N/A option for not required radio buttons and possible toggle on widget page
| Project: | Content Construction Kit (CCK) |
| Version: | 6.x-2.5 |
| Component: | Documentation |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | postponed |
Jump to:
If this has been reported before please respond with the link. I have searched and could not find anything about it.
I have several places on a college application where I use radio buttons, but these options are not required to initially fill out the application. I understand that when I set these to required that this N/A option will be removed. I don't want these required though and the default behavior should not be to add an option that I do not want. If I want the N/A option then I will put it in my self. I do not need the program to assume that I want it. This is a terrible addition that I honestly wonder how it happened.
I filed this as a bug report because cck is doing something that I do not believe it should do. I want the options I specified in the allowed values list and no more whether required or not required. I also understand that by default something is always selected and therefore making my fields required to solve this, would work OK in my situation. But I believe that the default should not automatically add an option. If I am in a minority in this then there MUST BE A WARNING about this quirky behavior.
#1
Since no one took an interest to this I went ahead and found a workaround myself. All I did was comment out the culprit below, starting with the if statement at line 393 of optionwidgets.module
// Add an empty choice for :// - non required radios
// - non required selects
/**
if (!$field['required']) {
if ((in_array($field['widget']['type'], array('optionwidgets_buttons', 'nodereference_buttons', 'userreference_buttons')) && !$field['multiple'])
|| (in_array($field['widget']['type'], array('optionwidgets_select', 'nodereference_select', 'userreference_select')))) {
$options = array('' => theme('optionwidgets_none', $field)) + $options;
}
}
*/
There should be some type of check box that can be selected to enable/disable whether this empty choice gets added to non required radios and selects. If I have some spare time I might make my own patch.
#2
Renamed to better describe what needs to be done.
#3
Sorry, but won't happen. Removing the n/a option means you cannot empty the field. 'no value' is a valid value for a non required field.
If the 'n/a' text bugs you, it can be overriden in the theme.
#4
The understandable need of having an "empty field state" for non-required fields should be accommodated by :
- displaying only the "allowed values" (without any N/A option)
- disallowing the possibility to specify another default value
In this way the empty field is the default compulsory state for non-required fields - no undesirable N/A option is displayed, while this state is in fact valid by default. This applies for radio buttons. For a drop down list for non-required fields the default empty value should be something like "please select a value" and no possibility of specifying another default value.
This is a more sensible approach than forcing the display of a compulsory visible N/A option for radio buttons, or a stupid blank space for drop-downs.
#5
#6
@yched
I don't think you get the point. I have certain options I want displayed and that's it. I don't want a module to automatically insert an N/A or a blank space. If I want that option then I can insert it myself. I do understand what you mean when you say that once a value is chosen then the field cannot be emptied (not true for power users), but when I am giving all of the options that are possible then this will not be a problem. The user is going to choose one of them, but should not be allowed to choose an N/A option unless it was added by me.
Think about it this way... I have several Yes/No questions on my college application which must be answered by either Yes or No. There should not be an option of N/A. Some of these questions are legal in nature and obviously cannot have this N/A option. The reason they are not required is so a user can fill out part of the application, save it, and come back to fill out the rest when they have all their information. Technically they need to answer these questions for their application to be complete (as far as our College Administration goes), but for just saving part of the application so they can finish the rest later they are deemed as not required (as far as FAPI submission goes).
I agree with abramo that there needs to be a checkbox that will display only the "allowed values" that a user supplies and disallows the default value. This way when the field is presented to the user there is nothing selected and they have the option of selecting something or not selecting it at all.
#7
jdwfly asked for previous report -- http://drupal.org/node/299490 is one.
I found this because I came looking for a solution to the unwanted N/A radio button I got.
#8
I have run into jdwfly's use cases a number of times. It doesn't make sense to me that there is no way to not show N/A when it it not intended to be an option for the user. Making the field required has no effect, in CCK 6.x-2.4 anyway.
#9
Sorry, disregard my last comment -- setting the field to required does work. Switching version back to OP's original value.
#10
I confirm markj comment. It's fixed in the current version by making the field mandatory. Makes sense.
#11
The whole point is not making it mandatory. I want to choose which options I want and thats it.
#12
I know what you mean. When I took my principle user through our node edit form, she asked me to explain why the drop-downs were marked as required. When I told her that we needed to make them required to eliminate the 'N/A' option she was confused. After I told her we had no other simple way of eliminating that option we moved on, but it did require a bit of negotiation.
#13
@jdwfly: There's no way to empty a single select list. So, the same behavior is implemented for radios. This is a design decission because CCK wants to offer a method to empty this kind of fields when they are not required. Nothing stops you from creating an alternative radios widget, or implement hook_form_alter() to remove the n/a if you don't want it. It's been said this won't happen in CCK, and I think you cannot force maintainers do what you want. This is implemented for a reason, and you may or may not agree, but you have the option to choose what it is, or do it yourself the way you wish.
#14
A drop down is a component that offers the users with a set of values to choose from. Same with radios.
If you do not want to force the user to select an option, then what you want to do is provide a N/A default choice. Otherwise, it is mandatory to choose one of the other options.
I.E.
-What is your gender: Male / Female (should be mandatory and therefore no n/a option)
-Do you love your kids: Yes / No / N/A (It is not mandatory to love your kids because you may not have any, then you select N/A)
#15
I wonder why this nonsense "N/A" was to be a part the radio field and it is not even removable on my version of Drupal even if I make the value required.
Now I have to use a Single On/Off check box to do the required job, that works for me.
#16
And when I use Single "On/Off" check box, the field title name is not displayed on content pages. Only the check box is displayed.
#17
Right... so basically they don't want to fix it, so it is marked as by design. What a wonderful feature to be included!
Anyway, I can understand your decision, but I still think it is wrong. I know there are many others who are working around this so called "feature" of cck. There must be some documentation either included with the module or on d.o under cck so people can eliminate the unwanted N/A option.
#18
@josephvalls
Making a field mandatory does not depend upon its options. It depends upon the person creating the form. If that person decides a certain field is mandatory they make it required regardless of the options they are using. If they decide that the field isn't mandatory then the field will not be required upon submission of the form. The options should be whatever the person creating the form decides. Adding a default N/A option to radio fields that are not required isn't always necessary, but it all depends on what the person creating the form wants.
I.E.
- What is your gender: Male / Female
Suppose I decide that I would like for the user to fill this out but I don't necessarily need it, but should they fill it out I want them to choose either male or female. In the CCK world the N/A option would be added and the question would look ridiculous. In the real world I understand and have seen examples where a programmer may add a not specified option, but he does not need to. If they are going to make a choice I don't want them to choose anything but Male and Female. I understand that once the user inputs either male or female they cannot clear the field, but that is what I wanted in the first place.
#19
Please, read #3 and #13.
Nothing stops you from coding another radios widget for CCK in contrib. If you wish this to be documented, nothing stops you from adding a page to the CCK handbook to describe how the n/a option could be removed.
#20
I just wanted to weigh in on this for the record... I agree that we should have bullets without the N/A requirement in non-required fields.
I very frequently encounter the issue of not wanting to have an N/A option but do not want to make the field a required element. An example is on a survey form, where I do not want to force folks to reply to every item, yet having to list the N/A in these examples is very intrusive.
I appreciate markus_petrux response and will do what I can to contribute, but this is an issue.
Thanks to all.
#21
Yes, I agree too. I think this is an issue. Please fix it.
#22
Hm. So I tried to remove this with hook_form_alter(). However, #options is nowhere to be found:
array'#type' => string 'optionwidgets_buttons' (length=21)
'#default_value' =>
array
0 =>
array
'value' => string '' (length=0)
'#required' => string '0' (length=1)
'#columns' =>
array
0 => string 'value' (length=5)
'#title' => string 'Choice' (length=6)
'#description' => string '' (length=0)
'#delta' => int 0
'#field_name' => string 'field_choice' (length=12)
'#type_name' => string 'article' (length=7)
'#tree' => boolean true
'#weight' => string '32' (length=2)
'#access' => boolean true
'#count' => int 9
This seems to be because these are added in the form element's #process step by optionwidgets_buttons_process().
I tried for awhile to add my own #process function at the end, but since the element's not initialized yet, it gets blown away by optionwidgets_elements().
So then I turned to an #after_build function on the element instead. It initially appeared that this also didn't give me #options, but I eventually found them buried inside of a 'value' sub-index. But, it turns out that was a red-herring, since unsetting $element['value']['#options'][''] didn't remove the choice from the widget display.
Just as I was about to give up, I noticed that the N/A, Yes, and No choices were repeated once again in the top-level $element array. Unsetting $element[''] in my #after_build function finally removed the option from view. Huzzah!!!
This was not even remotely pleasant to figure out, so I documented this at http://drupal.org/node/617694. So technically, this issue is now fixed.
But, a question to yched and other CCK maintainers: does it make sense to add a toggle for this on the widget settings form? It seems like a popular enough request. I understand why it's the way that it is (since without it, once you make a "Yes" or "No" choice, there's no going back to "Wait, I didn't meant to answer that...") but I don't think this is something that most people could've figured out on their own, and it would probably lighten your support request load.
#23
Heh. So after I twittered about my frustrations on this issue, chx piped up and noted that #after_build is a big hack (and probably why I had such issues with this) and suggested a better approach: using hook_elements() to extend the 'optionwidgets_buttons' type. So I've updated http://drupal.org/node/617694 accordingly. This is nice, because now it'll just do it everywhere without any performance overhead.
Still seems like an option to turn this on/off per-field would be helpful, though.
#24
Best practice is that radio buttons always have a default selected state specified per W3C recommendation and RFC1866. Not initially choosing an "on" element is handled differently in different browsers (the behavior is "undefined", as the W3C says) -- I seem to remember Safari automatically selecting the first option and Firefox not, but I could be mistaken.
http://www.w3.org/TR/html401/interact/forms.html#h-17.2.1
http://www.ietf.org/rfc/rfc1866.txt
Another usability issue is that once the user chooses a radio, they cannot unchoose it as they would be able to do with a N/A-type default. I would use a dropdown box instead of radio buttons if there should be no default.
I considered opening another ticket titled "Radio fields should always be required," but this seems as good as any place to put this comment I guess.
#25
I created #621366: Enforce comformance to W3C recommendations on radio buttons? as a follow-up to fix #24 in core (though not until D8 given the point in the cycle we're in). Thanks! I learned something new.
However, if you want to change the behaviour of radio buttons in CCK to make them always required, then yes, that should be a separate issue. This one is just about documenting how to remove the extra option. But feel free to cross-post it here once you create it, since hopefully all interested parties will see it.
#26
I haven't seen them chime in on this. I can already guess what the answer is though.
#27
In fact, this issue started in that direction.
I do not plan to spend time on this right now, however. So, unless yched and/or KarenS have the time soon, I think it's fine to say the future of this issue depends on what happens with #621366: Enforce comformance to W3C recommendations on radio buttons?.
I would like to add that if someone wants to change this behavior in CCK for their site, it is possible using hook_form_alter() + after_build callback. Here you can change the items in the radios element at will.