[development] What should we do with checkboxes?

Karoly Negyesi karoly at negyesi.net
Sun Dec 25 04:12:06 UTC 2005


Hi!

There are two kinds of elements where you get an array as the value:  
multiple selects and checkboxes. Upon submit of a multiselect, you get a  
list of selected values. With checkboxes, however you get an associative  
array of

something_that_has_the_information => 1

the information is in the *keys*. Note that #options have the same  
structure for multiselects and checkboxes:

something_that_has_the_information => display_this.

Currently, core has a problem: #default_value for checkboxes holds a list  
of something_that_has_the_information and it breaks serious havoc, because  
#value is either a list of these (when filled from #default_value) or it  
is an array of something_that_has_the_information => 1 when filled from  
submit. There is a special case: when you do not check any checkboxes on  
submit then it'll be copied from #default_value. Therefore the structure  
of #value changes per submit. This simply does not work, #value always  
needs to have the same structure.

Either we change #default_value structure or we change #value.

a) We could make #default_value an array of

something_that_has_the_information => 1

pairs. This would make it more complicated to build #default_value and
it's looking strange.

b) we change #value instead to be a list of selected values, like in  
multiselect. The code change in form.inc for this is minimal:

if ($form['type'] == 'checkboxes') {
    $edit = array_keys(array_filter($edit));
}

I like this one much better. The only problem is that somewhat it differs  
 from what you get from HTML -- but this is the information you actually  
need.

I feel like this is something for 4.8. For 4.7, I suggest a whole another  
approach: we take #default_value as a list of checked things (that's what  
we have now) and change it in form.inc to be a). If this feels hackish,  
there are 16 #type => checkboxes in core and if do either a) or b) then we  
need to check at least 16 screens but most of these are settings, so we  
need to check whether they take effect. For example, we need to check  
whether vocabulary settings result in the correct node form.

Happy holidays,

Karoly Negyesi


More information about the development mailing list