Issues

ZF-3149: Improvement for Zend_View ->

Description

In Zend Framework before 1.5 the Zend_View Helper FormCheckbox had the feature, that a hidden field with the value "0" was always set befor the checkbox. This was a very helpful feature because if you have a lot of checkboxes each with a boolean value which has to be to be stored in the database (e.g a char(1) DEFAULT '0'::bpchar in a postgres DB or SET '0','1' in a mysql DB) you want to have the value 0 if the checkbox is not checked. In the normal behaviour the checkbox value is not submitted if it is not checked.

It's really simple to make this improvement in FormCheckbox.php:



public function Checkbox($name, $value = null, $attribs = null) {
        
        $info = $this->_getInfo($name, $value, $attribs);
        extract($info); // name, id, value, attribs, options, listsep, disable
        
        // is the element checked?
        $checked = '';
        if (isset($attribs['checked']) && $attribs['checked']) {
            $checked = ' checked="checked"';
            unset($attribs['checked']);
        } elseif (isset($attribs['checked'])) {
            unset($attribs['checked']);
        }

        // is the element disabled?
        $disabled = '';
        if ($disable) {
            $disabled = ' disabled="disabled"';
        }

        // XHTML or HTML end tag?
        $endTag = ' />';
        if (($this->view instanceof Zend_View_Abstract) && !$this->view->doctype()->isXhtml()) {
            $endTag= '>';
        }

        // build the element
        // ADDED: here we built the hidden field
         $xhtml .= '_htmlAttribs($attribs)
               . $endTag;
        
        return $xhtml;
    }

It would be cool to have that again in this Helper.

Andy

Comments

Please evaluate and categorize/assign as necessary.

Scheduling for next mini release; this has affected many legacy apps.

Resolved in trunk and 1.5 release branch by r9324

I really take issue with this. It is poor design and breaks the model for those of us building forms with checkboxes.

If I wanted a hidden element then I should be able to extend the form checkbox to add it in, it's not rocket science. Unfortunately it does take some serious surgery to get rid of a hidden checkbox inserted without my even knowing about it.

It is a bad idea because: when working with the DOM in JavaScript a hidden element with the same name creates an array of elements. One of the effects of this is that a simple - if (oForm.my_checkbox.checked) will return undefined instead of true or false. changing it to if (oForm.my_checkbox[1].checked) should be my decision not one imposed on me.

The correct behaviour should be that an unchecked (unticked) checkbox should return no value on submit. It should be an option and not require a workaround.

"If I wanted a hidden element then I should be able to extend the form checkbox to add it in, it's not rocket science."

Having the possibility to set a parameter in the attribs would be the best way to handle it. I fully agree.

In most cases it is good to get a value also from a checkbox. Submitting a form with a input field results always in recieving the field - if it's empty or not. So why not having this behaviour with all form fields? To have full conformity with the HTML specs you are right if you expect the behaviour you described ('cause that's the way it is in HTML). The intention to have the hiodden field in this helper was because I always find it annoying when a checkbopx does not submit a value.

Cheers

Andy