Configuration in 3.0

[mark_story]

A while back I started a prototype to re-work cakephp application bootstrapping.  I had a few goals in mind:

* Remove the magic and still use conventions.
* Integrate composer, and update autoloading.
* Unify configuration and have *one* way to configure everything.

The last point raised a bit of contention as josé and I initially disagreed.  I've come think that josé was right though, but wanted to see if anyone had suggestions on how things could be made even better.  So far I have two possible ways configuration could be handled at:

https://github.com/markstory/cakephp/wiki/Unify-configuration

I've also got the in-progress branch here https://github.com/markstory/cakephp/compare/3.0...3.0-bootstrap

-Mark

[Juan Basso]

Why not both? The class will be responsible to parse the configuration and use the configuration, the Configure can be a "temporary" place to store the configuration. So, when the class need the configuration and it is not set, the class tries to load from Configure.

That way people can configure the class directly or thru Configure. Also, make the classes more independent.

Speaking in PHP, will can have a trait doing something like that:

function config($config = 'default') {

  if (!isset(static::$_config[$config])) {

    static::create($config, Configure::read('ClassName.' . $config));

  }

  return isset(static::$_config[$config]) ? static::$_config[$config] ? null;

}

It means that if you want to create directly to the class or use Configure, it will be a developer decision. By default I guess we should go with Configure.

Juan Basso

[mark_story]

My argument against both is it feels like an un-opinionated way to do things.  Generally CakePHP has opinions on how your code should be structured, how you should name classes, tables and columns.  It feels like this should be another one of those things the framework has an opinion on.  Providing two ways to do the same thing feels wrong to me.  It means double the documentation, double the learning, and makes integrating plugins more painful, as some will use one way, and others the other way.  Only having one way gives people direction and hopefully steers them down the one true path.

-Mark

[ADmad]

I too am not a fan of having 2 ways to achieve the same thing.

Yet I am unable to pick a clear personal preference from the two proposals provided. On a related note I feel cake is missing an Environment class of some kind. An easy way to configure email, db etc. based on your different environments dev, staging, production etc. For this a unified configurator as described in Proposal 2 would surely make things simpler.

[mark_story]

I had a decent talk with both José's last night about this and I think we both agreed that proposal 2 has the best chance of being good in the long term.

* It gives one simple API for all configuration.
* There is one convention for everything. Keeping true to the conventions over configuration.
* Its easy for plugin authors to use, and easy for app's to configure plugins from.
* It offers the simplest path for loading configuration from static files, or non-static sources e.g feature switches loaded from Redis.

It has a few architectural drawback:

* Dependency information is *pulled* out of Configure and constructed/handled in each adapter based class.  Interestingly enough this is similar to how all existing adapter classes work.  We never pass instances in when creating cache/logging setups.  But instead pass classnames + constructor parameters.
* The various adapter based classes will continue to need a drop() style method to remove the existing adapter instance when configuration is changed.

With enough of a decision reached, I'm going to continue working on the configuration changes post cakefest.

-Mark

[mark_story]

I've got many of the configuration related changes complete, and a pull request open for further discussion.

https://github.com/cakephp/cakephp/pull/860

-Mark

[William Golden]

Looks great Mark. Thanks for your hard work on this.

William Golden
http://codebomber.com