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

Proposed Component Name Zend_Config Improvements
Developer Notes Improvements
Proposers My E-mail Address
Revision 1.1 - 1 August 2006: Updated from community comments. (wiki revision: 20)

Table of Contents

1. Overview

This is essentially a group of improvements that I would like to add to the Zend_Config component to increase usability.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • The propsed improvements will leave the Zend_Config component completely backward compatible and pass all current unit tests.
  • The improvments will make it easier to retrieve configuration data on the fly.
  • the configuration file will be parsed once and configuration sections will be retrieved on a per need basis
  • a method will be added called Zend_Config_*::getSection() which will facilitate the retrieval of needed sections
  • any key/value pairs not within a section will be appended to the requested section upon component instantiation .

4. Dependencies on Other Framework Components

  • Zend_Exception
  • Zend_Config
  • Zend_Config_Exception

5. Theory of Operation

as a bit of back story, here is how these "improvements" were inspired. There have been several instances where, in the bootstrap file of my application, I would request a section from my config file, primarily using Zend_Config_Ini. There have been several times throughout the rest of my application where I have wanted to retrieve other more specific sections of my configuration. With the existing component, there are two ways I could go about this:

  • I could have just requested all of the sections I needed within the bootstrap. I didn't really like doing that though because why store all that processed configuration data for areas that you may not need it in.
  • just instanciate a new config object with the currently needed section, I didn't want to do this because of the regular opening and reparsing of the config file.

With these improvements, the configuration file gets parsed once during instanciation and is stored in its parsed state to allow for retrieval of any section at any time.

6. Milestones / Tasks

  • Milestone 1: Complete proposal
  • Milestone 2: Build working prototype and submit to incubator supporting use cases
  • Milestone 3: flush out to work with existing unit tests and provide unit tests for new methods
  • Milestone 4: flush out documentation

7. Class Index

  • Zend_Exception
  • Zend_Config_Exception
  • Zend_Config_Ini
  • Zend_Config_Xml
  • Zend_Config

8. Use Cases


Here is an example of how these updates can be used.

here is a sample ini configuration

now lets say in your boot strap you need to get an "environment" configuration. you would do something like this

you would now have a configuration object containing the data of the 'production' section, and in this case, I am adding it to the registry.

now lets suppose that later, in another controller or module, you have more specific data that you need. you would now be able to get that data like so

the complete ini data is stored a long with the config object. it is kept in its parsed state.
the getSection method also has 'native' options regarding how to return the configuration data

9. Class Skeletons



Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jul 07, 2007

    <p>I don't see what benefit you get over just doing</p>

    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    $config = new Zend_Config_Ini($file, null);
    <p>You'll then be able to do </p>
    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    $host = $config->production->db->host;
    $foo = $config->modulespecific->foo;

    <p>In order to support inheritance, Zend_Config_Ini already loads the entire INI file, so you don't affect performance anyway.</p>

  2. Jul 07, 2007

    <p>The point is to not have all of the sections loaded when they aren't being used, and to not have to re parse the file every time a new section is needed. the changes also add support for non section oriented key/value pairs.</p>

    1. Jul 13, 2007

      <p>But all of the sections <em>are</em> loaded - read from the config file and available via the config object - using the syntax Rob suggests. If you load all the sections at once, indicated by Rob, then the config file need not be reparsed to get <em>any</em> available section. I fail to see the necessity of these additions; seems like splitting hairs to me.</p>