Zend Framework: Zend_Config Component Proposal
| Proposed Component Name | Zend_Config |
|---|---|
| Developer Notes | http://framework.zend.com/wiki/display/ZFDEV/Zend_Config |
| Proposers | Rob Allen |
| Revision | 3.0 - 21 May 2006: Further reworking based on mailing list. (wiki revision: 13) |
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:
- http://www.zend.com/lists/fw-general/200604/msg00178.html. Unfortunately, I could not find the original post by Andi Gutmans in the archives.
- Other discussion can be found here: http://www.akrabat.com/index.php?s=Akrabat_Config
- Feedback on v1 from Zend is discussed here: http://www.zend.com/lists/fw-general/200605/msg00134.html
- Prototype code can be found here: http://www.akrabat.com/2006/05/13/zend_config-proposal-v2/
- Mailing list feedback on v2 is discussed here: http://www.zend.com/lists/fw-general/200605/msg00563.html
- Mailing list discussion on v2.1 is here: http://www.zend.com/lists/fw-general/200605/msg00748.html
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: namespace.property = 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 "db.name" 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
7. Class Index
- Zend_Config_Exception
- Zend_Config
- Zend_Config_Ini
8. Use Cases
Given the following:
Then we can do something like:
Example use with Zend_Db:
9. Class Skeletons
About the core team comment "This flag will not be allowed to be changed after the object is instantiated."
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
ZF Home Page
Code Browser
Wiki Dashboard
Original comments from the Framework core team
Reviewed by Zend team on Thursday, 20 Apr 2006.
Decision: Accepted (Conditionally, Keep as Pending)
We view configuration management as one of the more important
aspects of the Zend Framework and have spent considerable time
discussing this topic and our strategy.
We have accepted this proposal on the conditions that these
changes be made to it:
in its storage containers – only PHP memory. Storage containers (INI
files, database, etc) must be updated manually. Perhaps this will
change in the future, KISS for now.
memory if a flag is passed to the constructor. This flag will not be
allowed to be changed after the object is instantiated.
object will then be locked on this section for its lifetime. For example, an
INI file could be divided into the high-level sections "[Development]" and
"[Production]". One of these must be selected during the creation of the
object and later switching will not be permitted.
overloading and not array access.
configuration information.
"extends" as in PHP. Inheritence will be restricted to one section only,
i.e. nesting "extends" will be prohibited. This will be detected and an
exception raised on violation.
of configuration file formats can be read. However, the Zend Framework
itself will have only one format. This has yet to be decided and is not
considered part of this proposal.
Until these changes have been made, the proposal will stay as Pending.
After they have been made, the proposal move to Accepted and development
can begin in the incubator.