Revisit Configuration implementation

[codeguy]

We currently have two excellent classes from @designermonkey that enable powerful configuration management for Slim. However, we only have 6 default application settings for cookie default properties and the HTTP protocol version. Are the two configuration classes still necessary? Can we instead migrate this to a simple PHP array and manage it inside the PHP App::__construct() method, instead?

There is an argument to be made that the settings service is accessible to other services, but I'd rather keep third-party service settings isolated to those services.

[jeremykendall]

@codeguy Did I add the configuration classes? I don't remember doing so and my commit history doesn't seem to reflect that:

Master: https://github.com/slimphp/Slim/commits/master?author=jeremykendall Develop: https://github.com/slimphp/Slim/commits/develop?author=jeremykendall

I don't want to take credit for anyone else's hard work :-)

[codeguy]

Oh. Hmm. Sorry must have confused you with someone else! My bad. Question above is still valid.

EDIT: @designermonkey is who I was thinking of.

[JoeBengalen]

Maybe you could make it optional as the Config object implements ArrayAcces anyway.

Personally I do like to Config object and use it for much more than the 6 Slim options ;)

[akrabat]

What does the config object do that that an array doesn't?

[codeguy]

@akrabat That's my thinking. The config objects were originally built to support realtime translation between "foo.bar" and the related multi-dimensional array data (e.g., $array['foo']['bar']). But I'm not sure this is still necessary.

[akrabat]

I vote to remove. There are config components out that for people that want more power.

[codeguy]

Agreed. I still think @designermonkey's config tools would make an excellent service provider that could extend the default settings service.

[designermonkey]

The reason I did it was that it is a gateway to allowing config to be easily read from a file. All that would be needed is to replace the ConfigurationHandler appropriately.

I've gone further into this concept here: https://github.com/usebeagle/configuration and so would still be looking to patch over the default with something like this without any pain.

IMO, just dropping back to an array may make it difficult to replace with a custom version, so a class that can have a handler is still needed; Whether that be a service provider of sorts or something core.

Personally I do like to Config object and use it for much more than the 6 Slim options ;)

A very valid point. No application is just the options Slim provides.

Either way, I'm happy as long as it can be used like this easily. (I don't have a clue what to do for a service provider).

[codeguy]

@designermonkey I'd love to port your config code to a service provider that I can list on Slim's site as an optional addon.

class ConfigProvider extends PimpleServiceProvider
{
    public function register(\Pimple\Container $c)
    {
        $c->extend('settings', function ($settings, $c) {
            // $settings is array returned from original service
            // $c is container and \Slim\App instance

            return new \Your\Custom\Config($settings);
        });
    }
}

This assumes \Your\Custom\Config is your config class that implements the \ArrayAccess interface. You could then continue to fetch settings in the app itself like this:

$app->register(new \ConfigProvider);

$app->get('/foo', function ($req, $res, $args) {
    $httpVersion = $this['settings']['httpVersion'];
});

[geggleto]

:+1: for this.

[designermonkey]

:+1:

[designermonkey]

PS, if you want to use any of the Beagle stuff (github.com/usebeagle) please feel free, it's not going anywhere as is.