Caution: The documentation you are viewing is
for an older version of Zend Framework.
You can find the documentation of the current version at docs.zendframework.com
Theory of Operation - Zend_Config
Theory of Operation
Configuration data are made accessible to the Zend_Config constructor through an associative array, which may be multi-dimensional, in order to support organizing the data from general to specific. Concrete adapter classes adapt configuration data from storage to produce the associative array for the Zend_Config constructor. User scripts may provide such arrays directly to the Zend_Config constructor, without using an adapter class, since it may be appropriate to do so in certain situations.
Each configuration data array value becomes a property of the Zend_Config object. The key is used as the property name. If a value is itself an array, then the resulting object property is created as a new Zend_Config object, loaded with the array data. This occurs recursively, such that a hierarchy of configuration data may be created with any number of levels.
Zend_Config implements the Countable and Iterator interfaces in order to facilitate simple access to configuration data. Thus, one may use the » count() function and PHP constructs such as » foreach with Zend_Config objects.
By default, configuration data made available through Zend_Config are read-only, and an assignment (e.g., $config->database->host = 'example.com';) results in a thrown exception. This default behavior may be overridden through the constructor, however, to allow modification of data values. Also, when modifications are allowed, Zend_Config supports unsetting of values (i.e. unset($config->database->host)). The readOnly() method can be used to determine if modifications to a given Zend_Config object are allowed and the setReadOnly() method can be used to stop any further modifications to a Zend_Config object that was created allowing modifications.
Note: It is important not to confuse such in-memory modifications with saving configuration data out to specific storage media. Tools for creating and modifying configuration data for various storage media are out of scope with respect to Zend_Config. Third-party open source solutions are readily available for the purpose of creating and modifying configuration data for various storage media.
Adapter classes inherit from the Zend_Config class since they utilize its functionality.
The Zend_Config family of classes enables configuration data to be organized into sections. Zend_Config adapter objects may be loaded with a single specified section, multiple specified sections, or all sections (if none are specified).
Zend_Config adapter classes support a single inheritance model that enables configuration data to be inherited from one section of configuration data into another. This is provided in order to reduce or eliminate the need for duplicating configuration data for different purposes. An inheriting section may also override the values that it inherits through its parent section. Like PHP class inheritance, a section may inherit from a parent section, which may inherit from a grandparent section, and so on, but multiple inheritance (i.e., section C inheriting directly from parent sections A and B) is not supported.
If you have two Zend_Config objects, you can merge them into a single object using the merge() function. For example, given $config and $localConfig, you can merge data from $localConfig to $config using $config->merge($localConfig);. The items in $localConfig will override any items with the same name in $config.
Note: The Zend_Config object that is performing the merge must have been constructed to allow modifications, by passing TRUE as the second parameter of the constructor. The setReadOnly() method can then be used to prevent any further modifications after the merge is complete.