ZF-10733: Improvment of element addAttrib(...) -> create native methods for each attribute

Description

(This suggestion is maybe better for ZF2)

The problem with the addAttrib method is that it is used for all different HTML attributes.

I would suggest to implement for the most common attributes a native function: $elem->setSize(10); $elem->setMaxLength(20) $elem->setClass('...'); ...

The method's itself would be easy to implement public function setSize($size = 10){ $this->setAttrib('size', $size); }

Note: The methods would be vary for the different form elements. Because a checkbox don't have the "size" attribute.

But this would improve following things: * Ease the learning curve (http://framework.zend.com/wiki/display/…) * IDE can suggest you, which attributes are possible for the current element (in IDE an code) * If a attribute change, refactoring get's simplier -> refactoring a method is easier than just simple text * (optional): Adding validators when it's clear, behind the method: public function setMaxLength($length){ $this->setAttribute('maxlength', $length); $this->addValidator(new Zend_Validate_Lenght(array('max' => $length)); }

Disadvantage: * Code gets harder to maintain

Much work behind it, but I thing it would be a very good improvment.

Comments

I think, there is no need, because you can use "overloading":


$element->size = 10;
$element->class = 'notice';

[http://framework.zend.com/apidoc/core/…]

There are too many attributes and HTML5 is coming!

Sure you can also use this method. But exactly this is my point.

When you are new to the ZF you have first to crawl the documentation or the source code to find out, that this is possible. If there are clear methods, the questions go away, because you see what you can do (and not intend or read what it is possible).

Maybe the definition from "Ease the learning curve" should be clear defined befor implmenting this feature.

The argument that there are "too many" attributes don't count in my oppinion: http://w3.org/TR/html401/…

For select, optgroup, option there are only 7 additional attributes (not counting "name").

HTML5 is still not completely defined, and much applications will still have HTMl4 several years (IE6-IE8 will not support it!). Further HTML5 form elements are not complete different from HTML4.

Maybe thinking about this feature multiple times, but also from different view ports!

I think above in my listing there are some very good arguments for this feature.

@Martin: How would you approach compatibility among various versions of HTML? Some attributes are deprecated, others added.. So depending on the doctype, you'd have setter functions for attributes that are not valid under that doctype. In this sense, adding these functions would be less clear rather than more clear -- i.e. a user would call a set function, assuming it is taking care of generating valid HTML, but then the element would output invalid HTML...

@Martin ??But exactly this is my point.?? I understand completely what you want.

??When you are new to the ZF you have first to crawl the documentation or the source code to find out, that this is possible. If there are clear methods, the questions go away, because you see what you can do (and not intend or read what it is possible).?? This is also a problem of the documentation (Reference guide and API). The review of documentation is a topic for version 2. Currently, the description is just too poor and too short: (API)

{quote} __set Overloading: set object property {quote}

[http://framework.zend.com/apidoc/1.11/…]

??Further HTML5 form elements are not complete different from HTML4.?? True, but it adds even more attributes.

??I think above in my listing there are some very good arguments for this feature.?? Right, but I also agree with Marc.

@Marc: It's already implmented in ZF. The doctype comes in play how the tags get closed: http://akrabat.com/zend-framework/…

Currently you can say HTML4 form elements are the standard (with the difference of closing in XHTML)

Anyway it will be a problem with the gap from HTML4 to HTML5. There are a lot different elements or attributes - http://diveintohtml5.org/forms.html

Supporting both will sure be necessary. How will it be done there? If there is a solution, there will also be a solution for this problem.

Element attributes other than name and value are in fact just metadata, as defined in the Zend\Form proposals (ZF 2.0).

In my opinion metadata should be flexible and undefined. Making seperate setter/getter methods for attributes defined in web standards would suggest separation from the underlying data structure. Making this just a matter of good documentation.

Have a look at the version 2 and the complete new Zend\Form component.