repo_zf1/documentation/manual/en/module_specs/Zend_Config-TheoryOfOperation.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- Reviewed: no -->
<sect1 id="zend.config.theory_of_operation">
    <title>Theory of Operation</title>

    <para>
        Configuration data are made accessible to the <classname>Zend_Config</classname> 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
        <classname>Zend_Config</classname> constructor. User scripts may provide such arrays
        directly to the <classname>Zend_Config</classname> constructor, without using an adapter
        class, since it may be appropriate to do so in certain situations.
    </para>

    <para>
        Each configuration data array value becomes a property of the
        <classname>Zend_Config</classname> 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
        <classname>Zend_Config</classname> object, loaded with the array data. This occurs
        recursively, such that a hierarchy of configuration data may be created with any number of
        levels.
    </para>

    <para>
        <classname>Zend_Config</classname> implements the <emphasis>Countable</emphasis> and
        <emphasis>Iterator</emphasis> interfaces in order to facilitate simple access to
        configuration data. Thus, one may use the
        <ulink url="http://php.net/count"><methodname>count()</methodname></ulink>
        function and <acronym>PHP</acronym> constructs such as
        <ulink url="http://php.net/foreach"><emphasis>foreach</emphasis></ulink> with
        <classname>Zend_Config</classname> objects.
    </para>

    <para>
        By default, configuration data made available through <classname>Zend_Config</classname> are
        read-only, and an assignment (e.g.,
        <command>$config->database->host = 'example.com';</command>)
        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, <classname>Zend_Config</classname> supports unsetting of values (i.e.
        <methodname>unset($config->database->host)</methodname>). The
        <methodname>readOnly()</methodname> method can be used to determine if modifications to a
        given <classname>Zend_Config</classname> object are allowed and the
        <methodname>setReadOnly()</methodname> method can be used to stop any further modifications
        to a <classname>Zend_Config</classname> object that was created allowing modifications.
    </para>

    <note>
        <para>
            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
            <classname>Zend_Config</classname>. Third-party open source solutions are readily
            available for the purpose of creating and modifying configuration data for various
            storage media.
        </para>
    </note>

    <para>
        Adapter classes inherit from the <classname>Zend_Config</classname> class since they utilize
        its functionality.
    </para>

    <para>
        The <classname>Zend_Config</classname> family of classes enables configuration data to be
        organized into sections. <classname>Zend_Config</classname> adapter objects may be loaded
        with a single specified section, multiple specified sections, or all sections
        (if none are specified).
    </para>

    <para>
        <classname>Zend_Config</classname> 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 <acronym>PHP</acronym> 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.
    </para>

    <para>
        If you have two <classname>Zend_Config</classname> objects, you can merge them into a single
        object using the <methodname>merge()</methodname> function. For example, given
        <varname>$config</varname> and <varname>$localConfig</varname>, you can merge data from
        <varname>$localConfig</varname> to <varname>$config</varname> using
        <command>$config->merge($localConfig);</command>. The items in
        <varname>$localConfig</varname> will override any items with the same name in
        <varname>$config</varname>.
    </para>

    <note>
        <para>
            The <classname>Zend_Config</classname> object that is performing the merge must have
            been constructed to allow modifications, by passing <constant>TRUE</constant> as the
            second parameter of the constructor. The <methodname>setReadOnly()</methodname>
            method can then be used to prevent any further modifications after the merge is
            complete.
        </para>
    </note>
</sect1>
<!--
vim:se ts=4 sw=4 et:
-->