Developing software in the Real World

Zend_Config Proposal v2: Akrabat_Config (6)

A couple of weeks ago I received feedback from the Zend Framework core team about my Zend_Config proposal v1 and have finally found the time to updated the proposal accordingly.

The key points with my comments interspersed were:

– The Zend_Config class shall never modify configuration information in its storage containers
That’s ok – I never planned to do writing to ini file anyway.
– The configuration information should only be allow to be modified in memory if a flag is passed to the constructor. This flag will not be allowed to be changed after the object is instantiated.
I have to admit that I hadn’t considered the idea of allowing any modification of config data. It’s not hard to do though :)
– A top-level section name must be passed to the constructor and the config object will then be locked on this section for its lifetime.
This means that multiple ini files cannot be loaded. i.e. only one ini file is allowed per config object. It simplifies the code too! Note that given that you can do in-memory modification of a Zend_Config object, you could load multiple ini files and overwrite into one Zend_Config object.
– For convenience, configuration information should be available by property overloading and not array access.
This was discussed previously and I hadn’t got around to doing it.
– The config object should implement Iterator for easily listing configuration information.
This follows on logically from using property overloading.
– The special inheritence keyword (“include” in the proposal) shall be “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.
I like the idea of using “extends”. Personally, I would have preferred allowing nesting of extends as provides more power. Keeps life simple though.
– Additional config storage containers will be developed so that a variety 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.
I’m sticking with INI for now. As I said in the proposal, extending to other file formats wouldn’t be difficult, and we could then use a factory to pick the right one depending on file exension.

v2 of the Zend_Config proposal is:

And v0.6 of Akrabat_Config implements this spec. This time, I’ve put both the code and tests into a single zip file:

As always, thoughts and corrections welcome!

4 thoughts on “Zend_Config Proposal v2: Akrabat_Config (6)

  1. I ran your tests under Windows/Xampp/PHP 5.1.3/Zend Framework from Subversion 05 May 2006. They all ran correctly. Keep up the good work.

  2. As usual Rob, looks like a neat solution to what must be a frequent problem — I certainly need this capability (which is how I found your posting) and looks like your class would handle Smarty config files out of the box too — which could be useful. Unfortunately the world of Zend Framework has largely passed me by up to now. Got any useful "How to" references you could point me at? Thanks Rob.


  3. Hi Jonathan!

    The config has improved now and it's worth looking at what's in the Zend Framework incubator. THe class is now split differently: Zend_Config handles retriving values and is loaded via an array. I have written two classes that can load a file into Zend_Config: Zend_Config_Ini for ini files and Zend_Config_Array for standard PHP arrays. I'll have an XML adapter uploaded soonish too.

    Look at and for the code. and for the tests.

    As far as the Zend Framework itself is concerned, the most useful places to look are: – Official site. Check the manual! – A good tutorial

Thoughts? Leave a reply

Your email address will not be published. Required fields are marked *