Issues

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

Issue Type: New Feature Created: 2010-11-23T09:10:10.000+0000 Last Updated: 2012-06-08T16:31:08.000+0000 Status: Closed Fix version(s): Reporter: Martin Keckeis (thadafinser) Assignee: Frank Brückner (frosch) Tags: - Zend_Form

Related issues: Attachments:

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

Posted by Kai Uwe (kaiuwe) on 2010-11-23T10:03:07.000+0000

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

<pre class="highlight">
$element->size = 10;
$element->class = 'notice';

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

There are too many attributes and HTML5 is coming!

Posted by Martin Keckeis (thadafinser) on 2010-11-23T23:11:20.000+0000

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.

Posted by Marc Hodgins (mjh_ca) on 2010-11-23T23:50:11.000+0000

@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...

Posted by Kai Uwe (kaiuwe) on 2010-11-24T02:23:01.000+0000

@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.

Posted by Martin Keckeis (thadafinser) on 2010-11-24T10:07:38.000+0000

@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.

Posted by Richard Tuin (richardtuin) on 2011-01-20T13:56:23.000+0000

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.

Posted by Frank Brückner (frosch) on 2012-06-08T16:30:54.000+0000

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

Have you found an issue?

See the Overview section for more details.

Copyright

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

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

Contacts