Refactor app settings out of container

[codeguy]

Largely affects the App class.

[codeguy]

The point of this issue is to move settings management into the App class and away from reliance on the container. Like other major objects, folks can still use an external DIC to resolve the settings, but the resolved settings must still be injected into the App instance either during construction or after construction via a setter method.

I'll leave the App constructor alone for now, but I am going to add a public interface to the App class to manage settings. Some proposed methods include:

• setSettings(array $settings) (replace)
• getSettings()
• addSetting($key, $value)
• addSettings(array $settings) (append)
• hasSetting($key)
• removeSetting($key)

Internally, settings will be a Collection instance.

[akrabat]

What settings do we have? i.e. Do we need a collection at all?

[codeguy]

Actually, it seems to be just a single-dimensional array. So yeah, we can probably avoid the Collection instance and just use an array. 👍

[kminek]

i'm against storing settings as plain array. storing settings (and referring to settings) via collection object is better idea as it implements collection interface and objects are passed by reference everywhere. this way i could implement custom settings object which for instance reads json, xml, whatever files and pass it to App.

[geekish]

Agreeing with @kminek here... I use an extended Collection class for the settings so I can use my container of choice to inject it where I need it (example).

[kdubuc]

https://github.com/slimphp/Slim/issues/1923 is related, no ?

Anyway, I copy paste my reply here :

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 😉

[ghost]

I'd go for the first class collection approach as @kminek said