Slim: V4 proposal: Improve configuration

[akrabat]

It's a pain that we have to have a settings sub key in the first array to App's constructor when the majority don't put anything else in there. Maybe we should allow configuration of the DIC container via a second parameter to the App constructor?

$app = new App($config, $diConfig):

Also, we need documented support for different environments.

[geggleto]

I personally would prefer a setter approach for Slim settings, instead of having to pass in 2 arrays.
1) I think it's more readable.
2) We can likely do it in a chainable way.

$app = new App($diConfig)
                    ->setChunkSize(512)
                    ->setDisplayErrors(false);

[akrabat]

Harder to handle different environments that way

[silentworks]

@geggleto I am for the config array approach, you could even create a ArrayObject helper if you want autocomplete for your IDE or have a documented API of setting requirements.

[geggleto]

@silentworks I would prefer having the settings somewhere where they can be type-hinted... I can be very lazy [read efficient] and it's hard to remember the exact spelling of some of the config attributes.

[piotr-cz]

I don't like current state too, but shouldn't settings be contained in application container?

[maxmeffert]

I personally don't mind the current state, but I would welcome a separation of settings and DI configuration with two constructor parameters.

[piotr-cz]

IMHO separation is important in sense that settings and DI configuration should not both come from settings.php file (see my PR https://github.com/slimphp/Slim-Skeleton/pull/41).

But settings data should be accessible trough container, as other components (Controllers, Services) need to access it.

For example creating Piwik tracker service:

$container['PiwikTracker'] = function ($c) {

    $piwikSettings = $c['settings']['piwik'];

    return new \PiwikTracker(
        $piwikSettings['idSite'],
        $piwikSettings['apiUrl']
    );
}

So what about modified https://github.com/slimphp/Slim/issues/1923#issuecomment-231848142

$app = new App($diConfig)
              ->setSettings($settings);

[maxmeffert]

Why not keep separation throughout the whole application?

$container['PiwikTracker'] = function ($container, $settings) {

    $piwikSettings = $settings['piwik'];

    return new \PiwikTracker(
        $piwikSettings['idSite'],
        $piwikSettings['apiUrl']
    );
}

[akrabat]

@maxmeffert because Pimple's factory signature doesn't look like that.

[silentworks]

In its simplest form, the container we use is just a in memory key/value store, I consider settings pretty much keys/values, so not sure why settings doesn't fit into the container? Maybe because we are explicitly doing it, If this was implicit and hidden would we be still having this same conversation?

As I stated above, nothing stopping you from implementing your own ArrayObject to deal with autocomplete for IDEs https://github.com/slimphp/Slim/issues/1923#issuecomment-231872843

[nunocodex]

I think the best way is remove the settings key and move the options inside example slim.outputBuffering this have more sense and you can use the DI how you want.

[geggleto]

tagging @codeguy @akrabat

This should be revisited as we are removing the container requirement.

[geekish]

You have a Collection class in Slim, why not use it for a Settings class? I did.

[kdubuc]

What do you think about a Kernel which can be provided in the Slim constructor.

I build one : https://github.com/kdubuc/api/blob/master/src/Kernel.php

• Container-interop powered
• Can be fill with an array
• Reusable (can be use outside slim, in a cron / bus consumer to expose the same configurations / services)
• Strict definitions
• Can initialize the services thanks to ServiceProvider

The code isn't finalized, it is under active development, but the foundations are here 😉

[mnapoli]

As @namaless suggested already storing config values in the container like this make sense: slim.outputBuffering.

That's what I do in the PHP-DI bridge: http://php-di.org/doc/frameworks/slim.html#configuring-slim

    'settings.responseChunkSize' => 4096,
    'settings.outputBuffering' => 'append',
    'settings.determineRouteBeforeAppMiddleware' => false,
    'settings.displayErrorDetails' => false,

A container is key => value, a config is key => value too. It's much simpler to have 1 concept instead of 1.

[ivandokov]

You may consider adding https://github.com/vlucas/phpdotenv
It's super convenient to use. I don't have project without this package.

[mnapoli]

@ivandokov that is yet another way of configuring the application, container + config array + .env is just too much, it's too confusing.

Note that I don't have anything against that package and env variables, I use it too sometimes (PHP-DI can integrate directly with that). It's just an implementation detail of how I configure the container. The application (or framework) only uses the container, it's much simpler that way.

[lezhnev74]

Recently I tried this InteropConfig package: https://github.com/sandrokeil/interop-config
Looks promising, since I can manage my config independently under known rules.
I feel that this package may fit the Slim well.

[geniuscd]

I also dont use the other than $settings['settings'], my custom app variables are nested inside that array. But what i was looking for is to add some sort of development / production boilerplate settings without installing other packages.

[it-all]

I'm using 2 config files, not including the slim settings: config.php and env.php:

// in case of collision, env.php value overrides
$config = array_merge(require APP_ROOT . 'config/config.php', require APP_ROOT . 'config/env.php');

(not sure if it's better to have config last to override env - maybe you want to change some config values depending on your environment, but maybe some config values shouldn't be overriden)

https://github.com/it-all/BoutiqueCommerce/blob/master/config/env-sample.php

slim settings.php can then access $config

[chezzy]

Much better then

$userSettings = isset($values['settings']) ? $values['settings'] : [];
$this->registerDefaultServices($userSettings);

[akrabat]

App's constructor now takes the settings array directly - see #2104.