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 Component Proposal

Proposed Component Name Zend_Config
Developer Notes
Proposers Rob Allen
Revision 3.0 - 21 May 2006: Further reworking based on mailing list. (wiki revision: 14)

Table of Contents

1. Overview

Zend_Config is a very simple configuration file reader. It provides an easy means to read configuration files and access the data within them as a set of key-value pairs. It will support at least one nested level of data. Initially providing support for ini files, it should be easy to extend for other formats such as YAML.

2. References

Mailing list thread resurrected here:

3. Component Requirements, Constraints, and Acceptance Criteria

  • Ability to load configuration information from a single config file and provide access to the data as object properties.
  • A top level section name must be specified for loading.
  • Optional option to allow modification of the config data held in memory.
  • No ability to modify the original data in the config file.
  • For ini files, support for "namespaces" using the syntax: = value
  • Iterator is implemented for easily listing of configuration information.
  • The special inheritance keyword "extends" will be used to allow for including additional sections within this section. For ini files, the syntax would be: extends = section

4. Dependencies on Other Framework Components

  • Zend_Exception

5. Theory of Operation

Zend_Config loads and provides a property based interface to an array. The data are read only unless $allowModifications is set to true on construction. Zend_Config also implements Countable and Iterator to facilitate easy access to the data.

Sometimes it is necessary to get at a group of config variables as an array (e.g., the $config parameter in Zend_Db::factory()). Zend_Config provides the function "asArray()" to allow easy integration with such requirements.

Zend_Config_Ini is a class that loads ini files and creates and associative array for use by Zend_Config. It loads a single section from the specified ini file. It supports using the full stop character (".") in a key name to provide additional nesting levels. That is, a key named "" will be represented in the array as $data['db']['name'].

Zend_Config_ini also supports loading of keys from one section of the ini file into another section. This is done using a special keyword called "extends". It is possible for the parent section to itself extend from another section. Multiple inheritance, such that a section can extend
two or more other sections, is not permitted.

In order to make it easy to use with Zend_Config, Zend_Config_Ini has a static method, "load()", which loads the ini file and returns the array.

In the future, should there be demand for other config file types, other Zend_Config_XXX classes can be created for use by Zend_Config. The only requirement would be for such classes to be able to generate an associative array for loading into Zend_Config.

6. Milestones / Tasks

zone: Missing {zone-data:milestones}

7. Class Index

  • Zend_Config_Exception
  • Zend_Config
  • Zend_Config_Ini

8. Use Cases

Given the following:

myapp.ini file

Then we can do something like:

Example use with Zend_Db:

db.ini file

9. Class Skeletons



Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jun 15, 2006

    <p><strong>Original comments from the Framework core team</strong></p>

    <p>Reviewed by Zend team on Thursday, 20 Apr 2006.<br />
    Decision: Accepted (Conditionally, Keep as Pending)</p>

    <p>We view configuration management as one of the more important<br />
    aspects of the Zend Framework and have spent considerable time<br />
    discussing this topic and our strategy.</p>

    <p>We have accepted this proposal on the conditions that these<br />
    changes be made to it:</p>
    <ul class="alternate">
    <li>The Zend_Config class shall never modify configuration information<br />
    in its storage containers – only PHP memory. Storage containers (INI<br />
    files, database, etc) must be updated manually. Perhaps this will<br />
    change in the future, KISS for now.</li>

    <ul class="alternate">
    <li>The configuration information should only be allow to be modified in<br />
    memory if a flag is passed to the constructor. This flag will not be<br />
    allowed to be changed after the object is instantiated.</li>

    <ul class="alternate">
    <li>A top-level section name must be passed to the constructor and the config<br />
    object will then be locked on this section for its lifetime. For example, an<br />
    INI file could be divided into the high-level sections "[Development]" and<br />
    "[Production]". One of these must be selected during the creation of the<br />
    object and later switching will not be permitted.</li>

    <ul class="alternate">
    <li>For convenience, configuration information should be available by property<br />
    overloading and not array access.</li>

    <ul class="alternate">
    <li>The config object should implement Iterator for easily listing<br />
    configuration information.</li>

    <ul class="alternate">
    <li>The special inheritence keyword ("include" in the proposal) shall be<br />
    "extends" as in PHP. Inheritence will be restricted to one section only,<br />
    i.e. nesting "extends" will be prohibited. This will be detected and an<br />
    exception raised on violation.</li>

    <ul class="alternate">
    <li>Additional config storage containers will be developed so that a variety<br />
    of configuration file formats can be read. However, the Zend Framework<br />
    itself will have only one format. This has yet to be decided and is not<br />
    considered part of this proposal.</li>

    <p>Until these changes have been made, the proposal will stay as Pending.<br />
    After they have been made, the proposal move to Accepted and development<br />
    can begin in the incubator.</p>

  2. Jun 20, 2006

    <p>About the core team comment <em>"This flag will not be allowed to be changed after the object is instantiated."</em></p>

    <p>It seems like you may want to allow $allowModifications to changed from writable to read-only, but not from read-only to writable. I think it is quite possible that application initialization code may want load a configuration file, add to or modify it, and then set it to read-only for the rest of the application</p>

    1. Aug 09, 2006

      <p>I've certainly needed this pattern in past projects.</p>

  3. Jul 06, 2006

    <p>Why you don't propose a simple use same :</p>

    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    [all] = example
    db.connection = foo = bar
    db.password = pwd
    hostname =
    hostname = andi_box
    db.connection = localhost
    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    $obj = new Zend_Config(Zend_Config_Ini::load('myapp.ini'));

    print $obj['andi_dev']->hostname; // prints "andi_box"

    print $obj['andi_dev']>db>connection; // prints "localhost"

    print $obj['all']>db>name; // prints "bar"

    print $obj['all']>db>password; // prints "pwd"
    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    $obj = new Zend_Config(Zend_Config_Ini::load('myapp.ini'));

    print $obj->andi_dev->hostname; // prints "andi_box"

    print $obj->andi_dev->db->connection; // prints "localhost"

    print $obj->all->db->name; // prints "bar"

    print $obj->all->db->password; // prints "pwd"