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:
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.
On Wed, Aug 22, 2012 at 4:18 PM, mark_story <mark.st...@gmail.com> wrote:
> 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:
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.
On Thursday, 23 August 2012 21:03:36 UTC-4, Juan Basso wrote:
> 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
> On Wed, Aug 22, 2012 at 4:18 PM, mark_story <mark....@gmail.com<javascript:>
> > wrote:
>> 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:
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.
On Friday, August 24, 2012 8:10:17 AM UTC+5:30, mark_story wrote:
> 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
> On Thursday, 23 August 2012 21:03:36 UTC-4, Juan Basso wrote:
>> 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
>> On Wed, Aug 22, 2012 at 4:18 PM, mark_story <mark....@gmail.com> wrote:
>>> 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:
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.
On Wednesday, 29 August 2012 20:28:05 UTC+1, ADmad wrote:
> 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.
> On Friday, August 24, 2012 8:10:17 AM UTC+5:30, mark_story wrote:
>> 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
>> On Thursday, 23 August 2012 21:03:36 UTC-4, Juan Basso wrote:
>>> 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
>>> On Wed, Aug 22, 2012 at 4:18 PM, mark_story <mark....@gmail.com> wrote:
>>>> 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:
On Wednesday, 22 August 2012 16:18:38 UTC-4, mark_story wrote:
> 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:
On Wed, Sep 19, 2012 at 8:57 PM, mark_story <mark.st...@gmail.com> wrote:
> I've got many of the configuration related changes complete, and a pull
> request open for further discussion.
> On Wednesday, 22 August 2012 16:18:38 UTC-4, mark_story wrote:
>> 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:
