http://spyc.sourceforge.net
http://www.yaml.org/
http://en.wikipedia.org/wiki/YAML

http://misko.hevery.com/code-reviewers-guide/flaw-brittle-global-state-singletons/

XML was not created for human beings to read so if you are not using *TOOLS* to modify your configuration do not use XML. There is no reason to. Where INI has limitations YAML doesn’t. Which is extremely readable and very powerful. Or best if only developers will be changing the configuration it may be as well left as a PHP array which allows to have dynamic values.

I just had to deal with a similar, but different problem, of managing *multiple* config files for projects. When all project components aren’t in your control, or even all in the same language, config files proliferate and updating them to work properly on different environments is a painful process.

I wrote and open-sourced an app called config-magic that lets you easily manage multiple config files from a single “profile” config, thus allowing you to regenerate N config files for any box with a single command. You can store multiple profiles and thus easily re-configure any project checkout to target any environment in a matter of seconds.

Check it out: http://github.com/apinstein/config-magic

http://framework.zend.com/manual/en/zend.config.adapters.ini.html

What it does is basically the same as parse_ini_file, however it gives you the benefit to get deeper than 3rd level. By something like this:

webhost = http://www.example.com
database.adapter = pdo_mysql
database.params.host = db.example.com
database.params.username = dbuser

you can reach the username parameter by something like this:

$config = new Zend_Config_Ini(‘config.ini’);
echo $config->databaser->params->username;

You can also define different configuration options for different environments like production and testing.

public static function createFromDefaultConfig()
{
return self::createFromConfig(Config::getInstance());
}

public static function createFromConfig(Config $config)
{
return new self($config->get(‘db:username’)…);
}

class constants
- has disadvantage of only simple types – no string concat, no function assign, is final
- wouldn’t recommend for configuration

ini or xml file
- unless you cache the file in cache (APC, Memcache) it’s slow solution because of everytime disc usage
- would recommend only with cache

class properties
- using magic __get method with main switch of (hash map for speed) defined properties is good solution. It works well with namespaces, no additional cache handling necessary when using opcode cache, easy for autoload, you may decide whether accept or deny value change using __set magic method.
- would recommend