3.0 cache log config changes

[markstory]

After @lorenzo 's comments on my last pull request (#1517) I've added the ability to read config data back out of Cache and Log. In addition to that I've done a few other things.

• Made it simpler to inject built objects into Cache/Log.
• Made it simple to use a factory function to help with more complicated engine construction.
• Renamed 'engine' to 'className'. This is more conformant to the rest of CakePHP. engine will continue working though for now.

I also removed Cache.disable from Configure. I've always disliked this configure value. It is now part of the Cache class so it doesn't need to interact with Configure making the check cheaper, simpler and Cache more self contained.

I think there is an opportunity to extract config() and drop() into a trait if there are a few more similar uses. With only two uses it doesn't make much sense right now. But if another class re-uses the same pattern it will be useful.

I spent some time and drafted up some ideas on how config methods on other classes could work as well. Any feedback on that is more than welcome.

[jippi]

👍

except: there seem to be a lack of those newlines we also talked about in the other PR

and

there isn't any way to change "_enabled" without calling a method, thus not allowing cake to be configured / bootstrap from say, and environment ini file ?

[lorenzo]

I think this is a great idea and for the same reasons I think Cache::set() should get the axe

[markstory]

I'm glad I'm not the only person who hates Cache::set(). That method is all sorts of silly. I'm on board for removing it if others are. It adds a pile of complexity to Cache for almost no benefit other than making the calling code more complicated as well.

[lorenzo]

Good job mark! There is one failing test in travis that you might want to take a look to, something related to auto creating the tmp folders

[markstory]

@jippi Would you ever setup a deployed app with caching off? I couldn't think of a useful scenario where you'd want to configure a deployed application with caching disabled.

[markstory]

@lorenzo What did you think of the other examples/proposals in the wiki page?

[jippi]

@markstory I could do that, or have it disabled in dev and enable it in prod - its also just for consistency that you can configure everything in a simple manner without using php

[lorenzo]

@markstory I think it is heading a good direction, the only thing that i could not understand is what is the difference between Email::configTransport and Email::config

[jrbasso]

The config method from Log and Cache are almost identical. What do you think in make it a trait? Probably other classes will be able to use it too.

[markstory]

@jippi What if Cache::enabled() took a parameter to set the state? Kind of like a generic get/set that could be populated with data from a config file?

<?php
Cache::enabled(Configure::read('App.cacheEnabled'));

[markstory]

@jrbasso Yes they are almost identical. Once there is a third copy I'll extract it into a trait.

@lorenzo I thought it might be simpler code/API wise if transports and delivery profiles were separate. That way if your application had multiple delivery profiles that re-used the same transport you would be able to avoid duplicating the transport settings multiple times.

[lorenzo]

@markstory That's a cool idea, I always hated to configure the same transport for different profiles. I also like the Cache::enabled() thing better

[ADmad]

@lorenzo In 2.x we also have the problem that delivery config bled into transport. Eg. Doing $CakeEmail->config(array('log' => true)) the log key ends up in transport config too.

[jippi]

@markstory could work, but would require php to configure the app, and not just a configure load of an ini file

[markstory]

@lorenzo Yeah having to duplicate transport settings was painful. Also the problem @ADmad pointed out created ambiguity in what would happen when Email::config() was called.

@jippi The current cache and log config methods will each require at least 1 line of PHP code. For example if you were using Configure's features to load/use configuration files you would have to do something like:

<?php
// app/Config/bootstrap.php
Configure::config('default', new IniReader());
Configure::load('caching');
Configure::load('logging');

Log::config(Configure::read('Log'));
Cache::config(Configure::read('Log'));
Cache::enabled(Configure::read('Cache.enabled'));

The point of this and the last set of changes was to remove the magic, ability to get data out of sync and spooky action at a distance that not having to use any methods caused. I feel this code while 3 lines longer is far more transparent and consistent.

[markstory]

All non CS tests are now passing on this branch.