ZF-2976: Zend_View_Helper_FormRadio have no unique ids for javascript access

Issue Type:
Bug
Created:
2008-03-26T15:47:05.000+0000
Last Updated:
2013-03-14T10:29:39.000+0000
Status:
Open
Fix version(s):
  • 1.5.3 (28/Jul/08)
Reporter:
jaap vstr (jaapvstr)
Assignee:
None
Tags:
  • Zend_View
Related issues:
Attachments:

Description

As an inconstancy with other view helpers, formRadio doesn't give the radio buttons a unique id.

I came by this error while using Zend_Form, which depends on this View_Helper class

Zend_Form_Decorator_ViewHelper eventually calls the helper with something like seen below:


formRadio('subfrm', 'true', array('options' => array('true' => '', 'false' => ''), 'listsep' => ''));

This results in:

While the expected result would be something like:

A suggested fix would be:


// Wrap the radios in labels
            $radio = '_htmlAttribs($label_attribs) . '>'
                    . (('prepend' == $labelPlacement) ? $opt_label : '')
                    . '_htmlAttribs($attribs) 
                    . $endTag
                    . (('append' == $labelPlacement) ? $opt_label : '')
                    . '';

The preg replace is there to also address names with brackets. So subfrm[0] with value true would be converted to subfrm-0-true. It was copied from Zend_Form_Decorator_ViewHelper, so i think it's safe, but didn't create it.

Comments

Posted by jaap vstr (jaapvstr) on 2008-03-26T15:49:09.000+0000

Linked to ZF-2937, since that was the original filed bug report. However this bug should be categorized with Zend_View instead.

Posted by Wil Sinclair (wil) on 2008-03-31T16:10:03.000+0000

Please evaluate and categorize as necessary.

Posted by Anders Petersen (anpeters) on 2008-05-02T12:11:52.000+0000

The suggested fix does not work on names like "mainProducts[]" (to submit arrays when using Zend_View_Helper_FormMultiCheckbox). It would generate an id like "mainProducts[]-product1", which is invalid according to W3C. I used this instead: \ \

                    . ' id="' . rtrim(preg_replace('/\[([^\]]*)\]/', '-$1', $name), '-') .'-'. $this->view->escape($opt_value) . '"' //add this line

Posted by Matthew Weier O'Phinney (matthew) on 2008-05-09T12:50:07.000+0000

Scheduling for next mini release. Fix is non trivial, so have scheduled a good time alotment for dealing with it.

Posted by Matthew Weier O'Phinney (matthew) on 2008-07-25T09:09:44.000+0000

Resolved in trunk and 1.5 and 1.6 release branches.

Posted by Bernd Matzner (bmatzner) on 2008-09-28T14:41:13.000+0000

Using the option value to concatenate to element name as in the current implementation (1.6.1) may result in invalid option IDs, when using a non-ascii value (e.g. äöü as the option value results in ) I'd suggest using an option counter and add a option count number instead of the option value, which is just as useful, but avoids possible problems.

in FormRadio, instead of // generate ID $optId = $id . '-' . $filter->filter($opt_value);

this could be simply // generate ID $optNo ++; $optId = $id . '-' . $optNo; avoiding the need for an additional filter, which will always lead to unpredictable results.

Posted by Ralph Schindler (ralph) on 2011-02-17T14:59:09.000+0000

At this point, changing the id name of a formradio element would produce a BC break. We will address this at 2.0 time.