Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend_Config_Xml Attribute Support - Ben Scholzen Component Proposal

Proposed Component Name Zend_Config_Xml Attribute Support - Ben Scholzen
Developer Notes Attribute Support - Ben Scholzen
Proposers Ben Scholzen
Zend Liaison - Ralph Schindler
Revision 1.0 - 20 February 2008: Initial proposal.
1.1 - 20 February 2008: Prototype and unit tests finished. (wiki revision: 13)

Table of Contents

1. Overview

This proposal will extend Zend_Config_Xml to be able to use node attributes. This will make config files not only more readable, but also easier to handle and quite smaller.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • This component will keep the compatibility with prior xml config files.
  • This component will allow values given by parent nodes.
  • This component will allow a short form of parameter values.

4. Dependencies on Other Framework Components

  • Zend_Config

5. Theory of Operation

The Config is instantiated like before, and the usage nor the data structure will change in any way. Programmers just get the ability to write their configurations in a shorter way.

Parameters of a node can either be attribute values in a parent node (which may contain childs, but doesn't have to), or as sub-nodes of the parent. In this case, either the the classic style can be used (<key>value</key>) or one of the two new styles (<key value="value"/> or <param name="key" value="value"/>). To keep things backward compatible, a parameter with the key "extend" is not permitted in parent node attributes.

6. Milestones / Tasks

  • Milestone 1: [DONE] Proposal finished
  • Milestone 2: [DONE] Working prototype checked into
  • Milestone 3: [DONE] Unit tests exist, work, and are checked into
  • Milestone 4: [DONE] Proposal confirmation
  • Milestone 5: [DONE] Initial documentation exists.
  • Milestone 6: [DONE] Everything checked into incubator

7. Class Index

  • Zend_Config_Xml

8. Use Cases

The following examples will all result in the same data structure


Classic XML layout


Parent node attributes


Short params (variant 1)


Short params (variant 2)


Short params (variant 3)

9. Class Skeletons



zend_config zend_config Delete
config config Delete
xml xml Delete
attributes attributes Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Feb 20, 2008

    <p>I would very much like to see this happen in 1.6</p>

  2. Feb 20, 2008

    <ac:macro ac:name="unmigrated-wiki-markup"><ac:plain-text-body><![CDATA[Something I wanted to see some time ago, was the possibility to describe the type of the value, within an attribute.

    That could look like this:

    <host type="string">localhost</host>
    <username type="string"></username>
    <password type="string"></password>
    <dbname type="string"></dbname>
    <errorReporting type="int">0</errorReporting>

    Unknown macro: {/code}

    In most cases PHP can cast the right type, but there are cases where this fails.]]></ac:plain-text-body></ac:macro>

  3. Apr 14, 2008

    <p>In principle I like the idea though I worry about having too many ways to do the same thing which may make life harder for maintenance of config files long term.</p>



    1. Apr 14, 2008

      <p>Well, the one likes it this way, the other likes it that way. I have also implemented multiple ways since Short params (variant 2) allows having non letter characters as parameter names, like numbers. But I personally would use Short params (variant 3) more often. Short params (variant 1) is for those guys who like the classic way but dislike to always name the parameter name twice (in the opening and the closing tag).</p>

  4. May 20, 2008

    <ac:macro ac:name="note"><ac:parameter ac:name="title">Zend Comments</ac:parameter><ac:rich-text-body>

    <p>This proposal has been accepted for Standard Library Incubator inclusion provided the following changes:</p>

    <li>remove support for the param / name / key conventional usage as it is introducing an overloading of node names within xml that is not desired.</li>


    1. Jun 01, 2008

      <p>I agree with that. I have removed the param / name / key conventional usage from my SVN repos (and also refactored it to fit the new coding standard).</p>