10-04-2016, 10:19 AM
Some pretty big-name projects still use php-script-based configuration for at least a portion of their configuration. THere are some things that are just easier to do in PHP than in the DB...
For instance, I just added a 'userspice/admin_groups' and it is set as an array. You *can* make this work within the DB, but to make sure the user enters the data appropriately you're going to have to write a special form with appropriate validation and etc. All that when they could have written "array(2,7,19)"...
The end result of having "fancy DB" configuration is that developers tend to hardcode their chosen defaults - to make it configurable is just too much of a pain. Whereas if I can write this code:
if (!$adminGroups = Config::get('userspice/admin_groups'))
$adminGroups = [2];
And not think about it anymore then I will make it a habit to *always* allow that kind of configuration override.
It may be worth thinking about leaving options open for code-based configuration...
For instance, I just added a 'userspice/admin_groups' and it is set as an array. You *can* make this work within the DB, but to make sure the user enters the data appropriately you're going to have to write a special form with appropriate validation and etc. All that when they could have written "array(2,7,19)"...
The end result of having "fancy DB" configuration is that developers tend to hardcode their chosen defaults - to make it configurable is just too much of a pain. Whereas if I can write this code:
if (!$adminGroups = Config::get('userspice/admin_groups'))
$adminGroups = [2];
And not think about it anymore then I will make it a habit to *always* allow that kind of configuration override.
It may be worth thinking about leaving options open for code-based configuration...