Hi Matthieu, I can not reproduce your problem.

// View
$view = new Zend_View();
$view->setEncoding('utf-8');
$view->doctype('XHTML1_STRICT');

// Form
$form = new Zend_Form();

// Element
$form->addElement(
    'text',
    'foo',
    array(
        'label' => 'Foo',
        'decorators' => array(
            'ViewHelper',
            'Errors',
            array(
                // Decorator name
                'Description',
                // Decorator options
                array(
                    'tag'   => 'p',
                    'class' => 'description',
                ),
            ),
            array(
                // Decorator name
                array(
                    'element' => 'HtmlTag',
                ),
                array(
                    'tag' => 'dd',
                ),
            ),
            array(
                // Decorator name
                array(
                    'closeDt' => 'HtmlTag',
                ),
                // Decorator options
                array(
                    'tag'       => 'dt',
                    'closeOnly' => true,
                    'placement' => 'prepend'
                ),
            ),
            'Label',
            array(
                // Decorator name
                array(
                    'openDt' => 'HtmlTag',
                ),
                // Decorator options
                array(
                    'tag'      => 'dt',
                    'openOnly' => true,
                    'class'    => 'bar',
                ),
            ),
        ),
    )
);

echo $form->render($view);

Callback and ViewScript are also default decorators.

Hi Kai,

We can of course use a specific list of decorators, but the goal here is to use the default ones, loaded by Zend_Form_Element::loadDefaultDecorators().

The point is to use only a simple line to pass the 'tagClass' parameter to the Label decorator automatically applied, i.e. :

$element->getDecorator('label')->setOption('tagClass', 'myClass ');

That tagClass would be used by the Label decorator when(/if) calling HtmlTag internally to add a wrapper.

Right now we can add a class to the DD definition with quite the same syntax ( $element->getDecorator('HtmlTag')->setOption('class', 'myClass'); ) so it would feel natural to be able to do this kind of thing for the DT also. P

This is way more concise than having to redeclare all default decorators manually to achieve the same goal, don't you think ?

Actually I already have modified the concerned file to do so, and my CLA just got validated, I just need to figure out how to submit a file. Surprisingly enough, this seems like the hard part of contributing.

It was clear to me from the beginning. But why is it not in your description of the problem?

Seems to me it is, as long as you understand "default decorators" as the decorators being applied by default, not as the actual existing decorators in the zf lib.

Standard vs. Default ;-)

Indeed. I stand by my 'default' ;) Any tip on how I can post the modified Zend_Form_Decorator_Label ?

I think you need first the CLA. Then you can add a file. In the left sidebar there is a link (under the headline "functions").

This is a modified version of Zend_Form_Decorator_Label allowing to set a class on its DT wrapper

That didn't seem to me like the right place, but well... if you say so. I'll just close the ticket and see what happens then ;)

added the functionnality requested

Not to fast! Please add a patch file and write unit test!

• No unit tests
• No patch file

the patch file

unit test

patch file and unit test done. I guess this it it... Let me know if something is still missing

Please do not close an issue when not all work is done!

• Add a patch file for tests.
• The comment of your method is wrong.

This is a case for the component maintainer!

Kai, what is wrong with the comment ? what do you mean by "This is a case for the component maintainer!" ?

patch for the test

Matthieu -- he means that until the patch is applied, you shouldn't close it. :)

Patches applied to trunk and 1.11 release branch.

Thanks for the info, Matthew. That link was very tempting ;) Perhaps it'd be better just not to have the power to close/resolve at all, then, if we can't fill all the requirements to do so.

Sweet :) Thanks man, you just officalized my first contribution.

new patch from current version integrating the tagClass option in the comments

please someone integrate this new patch so that the added option is described in the class comments

anyone to push that ?