Zend_Config_Xml enables developers to store configuration data in a simple XML format and read them
via nested object property syntax. The root element of the XML file is irrelevant and may be named arbitrarily.
The first level of XML elements correspond with configuration data sections. The XML format supports
hierarchical organization through nesting of XML elements below the section-level elements. The content of a
leaf-level XML element corresponds to the value of a configuration datum. Section inheritance is supported by a
special XML attribute named
extends, and the value of this attribute corresponds with the section
from which data are to be inherited by the extending section.
Note: Return type
Configuration data read into
Zend_Config_Xmlare always returned as strings. Conversion of data from strings to other types is left to developers to suit their particular needs.
Example #1 Using Zend_Config_Xml
This example illustrates a basic use of
Zend_Config_Xml for loading configuration data from an
XML file. In this example there are configuration data for both a production system and for a staging
system. Because the staging system configuration data are very similar to those for production, the staging
section inherits from the production section. In this case, the decision is arbitrary and could have been
written conversely, with the production section inheriting from the staging section, though this may not be
the case for more complex situations. Suppose, then, that the following configuration data are contained in
www.example.com pdo_mysql db.example.com dbuser secret dbname dev.example.com devuser devsecret
Next, assume that the application developer needs the staging configuration data from the XML file. It is a simple matter to load these data by specifying the XML file and the staging section:
database->params->host; // prints "dev.example.com" echo $config->database->params->dbname; // prints "dbname"
Example #2 Using tag attributes in Zend_Config_Xml
Zend_Config_Xml also supports two additional ways of defining nodes in the configuration. Both make use
of attributes. Since the
extends and the
value attributes are reserved keywords
(the latter one by the the second way of using attributes), they may not be used. The first way of
making usage of attributes is to add attributes in a parent nodes, which then will be translated into
children of that node:
The other way does not really shorten the config, but keeps it easier to maintain since you don't have to write
the tag-name twice. You simply create an empty tag, which contains it's value withing the