Config Settings Usability

[jim-parry]

Is there a reason why all of the application/Config classes should not be in system/Config?
It seems to me that the ones in application/Config should extend the ones under system/, and contain commented properties/settings, and methods, that a developer could over-ride. Detailed descriptions could be in either place.

The way it sits now, any changes to any configs in the framework will require a developer to reintegrate the "new, improved" stuff manually into the application/Config folder in each of their projects, rather than just having to worry about whatever changed.

If the intent is that a ".env" file provide for project-level customization, why do we need the classes in application/config.

The details might differ slightly between config classes, but the above feels like a reasonable & O-O approach to me.

[lonnieezell]

It's only unusable because you're developing a site with a framework that's under heavy development. :)

First - .env files are for environment configuration, not application configuration. They just provide a way for server-specific settings to be modified and override whatever the defaults were, both keeping sensitive info out of the repo and allowing multiple devs on a team to easily override the settings. But the application settings are still the defaults.

While we could do them all in system with copies in application, all you really gain is a slight performance hit during every request as 2 files have to be loaded instead of one. The vast majority of the time there will be few, if any, configuration setting changes in each official release. It's the same as it is with all previous versions of CI.

The way I see it, these are settings that are application-specific, not system-specific so they belong in the application. Plus - I'm already fighting a losing battle with performance :)

But really, once an official release is made, I don't see them changing much. If a new major feature is added, it will likely have its own config file. We just have to document any changes in the change log and I think we're good.

[jim-parry]

Ok. I will table the suggestion for now, and re-examine the notion once we have progressed much further along :-)