Configuration API

[Ingo Schommer]

Summing up discussion from http://groups.google.com/group/silverstripe-dev/browse_thread/thread/f92da811fc0d5cb4

# sam:
This is a limitation of our config system generally. In my opinion,
it would be best to stick with the conventional configuration
architecture, even if it does add an unnecessary auto-load. Adding a
custom-hack for a single module is just going to confuse things.
Having said that, maybe it's time to think about a new way of dealing
with configuration settings. The current config system has the
following options:
* You wind up getting unnecessary auto-loads on every page request.
* You have to write a lot of scaffold to allow for configuration
options.
* It's near-impossible to write a web-interface to edit
configuration
options.
The main advantage of the current system is that it's scriptable.
You
can put a config option in a conditional, such as:
if(Director::isDev()) RecaptchaField::set_api_key("dev_key");
else RecaptchaField::set_api_key("live_key");
I think that it's important that we still allow for this kind of
construct, but we should recognised that the majority of config
options don't need this kind of setup.
We could move towards having a file such as silverstripe.ini a more
traditional "configuration file" set-up, where we have namespaced
configuration items:
[RecaptchaField]
api_key = XXX
other_parameter = YYY
We could potentially choose to use parse_ini_file() to read these
files http://nz.php.net/manual/en/function.parse-ini-file.php.
Note that ensuring the security of the .ini files is critical. That
could potentially be done with the .htaccess file, or by making
the .ini file a .php file that outputted no content.
We could leave support for the _config.php files there for developers
to do special things with config, but we would move most of the
configuration burden to the config files.
We could potentially also have built-in support for silverstripe-
dev.ini, silverstripe-test.ini, silverstripe-live.ini. Of course,
these would be included after silverstripe.ini and _config.php, as
these files would be instrumental in determining which
environment_type you were set to.
I would like to hear everyone's thoughts on the configuration system;
it would be good to do a revamp of this for v2.3.


# sig
My only issue with
[section]
option=setting
Stuff is that it takes us away from PHP code's ability to be
programatically powerful; there's no logic you can wrap around that.
Do
the benefits of the above syntax outweigh limiting your flexibility?


# sam
Another option is to keep the config in _config.php. We have a
method
like Config::set() to load the configuration variables.
Config::set("RecaptchaField.api_key", "xxx");
And if we wanted to implement a web-based configuration system, we
could do so with a block along the lines of this:
/* AUTOCONFIGURE START */
Config::set(array(
"RecaptchaField.api_key" => "xxx",
"RecaptchaField.other_key" => "yyy",
));
/* AUTOCONFIGURE END */

# michael gall
I really think we should try and work a system that doesn't need to do
those
unnecessary autoloads, I'm not sure how that could work, possibly a
callback
from the Autoload system, to the config system. I've been doing a lot
of
investigation into performance/memory and that certainly can be an
issue.