Zend Framework

leacking unnecessary attributes into html source. viewScript + helper

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Won't Fix
  • Affects Version/s: None
  • Fix Version/s: 1.10.0
  • Component/s: Zend_Form
  • Labels:
    None
  • Fix Version Priority:
    Nice to Have

Description

viewScript and helper are set as attributes to elements when source is rendered...
I see sample solution -> Zend_Form_Decorator_Image::$_attribBlacklist
But only there it is implemented.
Should be done for all Elements.

$el = new Zend_Form_Element_Select('el_name');
        $el->viewScript = 'index/ba.html';
        $el->setDecorators(array(
                                array('ViewScript', array('class' => 'form element')),
                                //array('ViewHelper', array('helper' => 'formSelect'))
                                ));

        $form->addElement($el);

output:
<select name="el_name" id="el_name" helper="formSelect" viewScript="index/ba.html">

Activity

Hide
Julian Davchev added a comment -

Setting to Zend_Form componnent...forgot to mention

Show
Julian Davchev added a comment - Setting to Zend_Form componnent...forgot to mention
Hide
Matthew Weier O'Phinney added a comment -

While I can see this as nice when validating against w3c, there are applications where having arbitrary attributes can be useful – dojo and other JS toolkits utilize custom attributes to configure elements.

Any solution such as this (whitelisting or blacklisting) should be configurable – i.e., it can be either on or off by default, with methods or configuration options to toggle the behavior.

Show
Matthew Weier O'Phinney added a comment - While I can see this as nice when validating against w3c, there are applications where having arbitrary attributes can be useful – dojo and other JS toolkits utilize custom attributes to configure elements. Any solution such as this (whitelisting or blacklisting) should be configurable – i.e., it can be either on or off by default, with methods or configuration options to toggle the behavior.
Hide
Matthew Weier O'Phinney added a comment -

Tentatively scheduling for next minor release. Will require significant amount of work to make form decorators/view helpers comply with w3c specifications, and the benefit, while nice, is one that is negligible.

Show
Matthew Weier O'Phinney added a comment - Tentatively scheduling for next minor release. Will require significant amount of work to make form decorators/view helpers comply with w3c specifications, and the benefit, while nice, is one that is negligible.
Hide
Julian Davchev added a comment -

Well then, perhaps postpone this for later. Maybe not worth so much work if little benefit - never thought of applications needing arbitrary attributes. I just thought of this as bug and from my point of view wasn't so much work. Of course you have much better overview in Zend_Form and the like. I see no votes here so I guess best option is don't touch at all for now.

Show
Julian Davchev added a comment - Well then, perhaps postpone this for later. Maybe not worth so much work if little benefit - never thought of applications needing arbitrary attributes. I just thought of this as bug and from my point of view wasn't so much work. Of course you have much better overview in Zend_Form and the like. I see no votes here so I guess best option is don't touch at all for now.
Hide
Matthew Weier O'Phinney added a comment -

Too many moving parts. Some parts can be fixed on a case-by-case basis, but a sweeping change to blacklisting would break too many other areas at this time.

Show
Matthew Weier O'Phinney added a comment - Too many moving parts. Some parts can be fixed on a case-by-case basis, but a sweeping change to blacklisting would break too many other areas at this time.

People

Vote (4)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: