ZF-5197: Decorator aliases are lost when Zend_Form_Element_Captcha adds its own decorators in 'render' method

Issue Type: Sub-task Created: 2008-12-10T03:23:13.000+0000 Last Updated: 2010-06-19T10:43:08.000+0000 Status: Resolved Fix version(s): - 1.10.6 (22/Jun/10)

Reporter: Andrei Nikolov (viperx) Assignee: Christian Albrecht (alab) Tags: - Zend_Form

Related issues: - ZF-9168

Attachments: - Element.diff


Reproduce code:

      $captcha = new Zend_Form_Element_Captcha('captcha', array(
            'captcha' => array(
                'captcha' => 'Image',
                'wordLen' => 6,
                'timeout' => 300,
                'font' => Zend_Registry::get('siteRootDir') . '/application/sketchh.ttf',

            //captcha decorator are placed at the begining of the array by default by 'render' method
            array('decorator' => array('foo' => 'HtmlTag'), 'options' => array('tag' => 'span')),                
            array('decorator' => array('bar' => 'HtmlTag'), 'options' => array('tag' => 'div')),

what we expect is to have something like this:


but the result is this:


The problem is that the aliases of the decorators (foo and bar) are lost while the 'render' method of Zend_Form_Element_Captcha adds its own decorators at the begining of the decorators array. This is done by "array_unshift" and then call to "setDecorators" but "setDecorators" in fact removes all current decorators and adds the new one with "addDecorators". There we have

foreach ($decorators as $decoratorInfo)

and here in fact the alias of the decorator is lost (in this case the alias is the index of the decorator in the array)


Posted by Stanislav Malyshev (stas) on 2009-02-27T12:27:43.000+0000

Looks like defect in Zend_Form_Element::addDecorators not in Captcha. Matthew, could you take a look?

Posted by Christian Heinrich (shurakai) on 2009-06-04T11:50:16.000+0000

Yes, as you correctly assumed, the problem is located in Zend_Form_Element, but in addDecorator() (without the s!)

The problem is that all decorators are given as objects, therefore addDecorator() will determine the classname and save the decorators with this classname as the index.

Therefore, if you use multiple decorators of the same kind, they will be overwritten.

Version: 1.8

Posted by Matthew Weier O'Phinney (matthew) on 2009-06-04T13:10:51.000+0000

You can add concrete instances using aliasing as well:

<pre class="highlight">
$form->addElement('text', 'foo', array(
    'decorators' => array(
        array(array('Foo' => new My_Decorator_Foo())),

You can even do it with addDecorator():

$element->addDecorator(array('Foo' => new My_Decorator_Foo())); ```

Posted by Jesus Ruiz-Ayucar Vazquez (chuso) on 2009-07-04T15:18:56.000+0000

I have attached a patch which works to me. It changes the way Zend_Form_Element_Captcha::render() adds its decorators.

Posted by Christian Heinrich (shurakai) on 2009-08-24T06:03:40.000+0000

This issue still exists in 1.9.1

Matthew, I use to add my decorators in a derived formclass like this:

$this->setElementDecorators(array( array(array('biglabelClose' => 'HtmlTag'), array('tag' => 'div', 'closeOnly' => true, 'placement' => Zend_Form_Decorator_Abstract::PREPEND )), array('Label', array('placement' => Zend_Form_Decorator_Abstract::PREPEND)), array(array('biglabelOpen' => 'HtmlTag'), array('tag' => 'div', 'openOnly' => true, 'class' => 'biglabel', 'placement' => Zend_Form_Decorator_Abstract::PREPEND)) ) );

Doing it this way, the decorators with the aliases will be overwritten due to the way of saving in addDecorator.

However, the patch from Jesus works for me but should be reviewed; there have been a lot of whitespace changings.

Posted by Matthew Weier O'Phinney (matthew) on 2009-08-24T07:26:53.000+0000

@Christian H.: Of course it still exists in 1.9.1 - the patch has not yet been reviewed or applied.

Posted by Dominik Bulaj (webit) on 2009-12-03T03:11:37.000+0000

@Matthew - why so many bug hunt days didn't resove that issue? It's quite old and annoying issue. Any plans to fix it in near future?

Posted by Matthew Weier O'Phinney (matthew) on 2009-12-03T04:59:13.000+0000

@Dominik -- Please be more polite when bumping issues. My own time during the bug hunt days is basically spent reviewing patch submissions and commits that occur during the bug hunt. The various participants in the bug hunt work on the issues that affect them personally typically. Additionally, if you look at the backlog of issues, the shear volume means that we simply will not get to them all on any given bug hunt.

One problem with this particular patch is that it does not include unit tests, which means that whomever considers applying it will also need to create a reproduce case and capture it as a test -- which means it's a non-trivial amount of time to apply.

If you want this issue resolved faster, help by submitting a unit test case.

Posted by Hendri Smit (hendri.smit) on 2010-01-25T05:49:42.000+0000

The patch provided is incorrect. It may work in some cases but the changes made simply add the captcha decorators on top of the decorator stack. They should be rendered first and need to be at the bottom of the stack as is currently the case. Imo the proposed fix for case ZF-7552 is the way to go for this issue.

Posted by Mickael Perraud (mikaelkael) on 2010-06-06T08:01:09.000+0000

Change component

Posted by Christian Albrecht (alab) on 2010-06-19T10:43:08.000+0000

Fixed in r22464 and merged into 1.10 release branch

Have you found an issue?

See the Overview section for more details.


© 2006-2018 by Zend, a Rogue Wave Company. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.