Posted 07 October 2011 - 08:01 AM
Posted 10 October 2011 - 12:57 PM
You can have benefits if you develop a web application for Average Joe with customizable settings.
Posted 10 October 2011 - 03:03 PM
Posted 12 October 2011 - 02:28 AM
Site name, caching settings etc. are common settings for the Average Joe user and, actually, they are "hardcoded" into the yii config file (a file that the Average Joe shouldn't touch).
Posted 11 April 2012 - 05:42 AM
$newSettings = array("components" => array("foo" => array("class" => "Foo"))); file_put_contents(Yii::getPathOfAlias('application.config.custom').'.php', '<?php return '.var_export($newSettings,true).';');
Although this does scrub any comments in the config file.
The real problem with either approach is building the UI. You end up needing a separate form model for literally every component that you want the user to be able to configure, as well as form models for any components which that editable component users. So for example, if you want to make the URL manager configurable you need a model for the url manager itself, a model for url rules and a UI that ties it all together. I've actually done this, it's thousands of lines of code just for 2 components. Add the db, cache, session handler, auth manager, asset manager, client script etc, not to mention custom components, and you end up with a lot of code to write and maintain.
But the biggest problem of all - making this UI intuitive to end users. It's all very well allowing them to configure e.g. $defaultParams on an URL rule but how do you explain that to them in a way non developers can understand? and can you do that for every configurable property of every configurable component?
Don't underestimate the difficulty of this task
Posted 11 April 2012 - 08:16 AM
This post has been edited by ekerazha: 11 April 2012 - 08:22 AM
Posted 11 April 2012 - 08:36 AM
This is the hard bit. The other hard bit is deciding which things can be configured, because obviously if you're loading the config from the db, the db itself cannot be configurable, nor can the cache since presumably you'll be caching these values.
Posted 12 April 2012 - 12:46 PM
This post has been edited by ekerazha: 12 April 2012 - 12:53 PM
Posted 12 April 2012 - 01:11 PM
I already did, but to recap:
Here's the parser
$config = include "path/to/file.php";
Here's the writer:
$newSettings = array("components" => array("foo" => array("class" => "Foo"))); file_put_contents('path/to/file.php', '<?php return '.var_export($newSettings,true).';');
Anyway, you haven't addressed my points about UI...
Posted 13 April 2012 - 03:13 AM
$config = include "path/to/file.php";
How do you use that $config var? Yeah we can just import the config file but we have to read the config values every time and overwrite the config file everytime and if you add config values you have to change the reading function to read the new values... haven't we?
Posted 13 April 2012 - 04:26 AM
1. Read the config into an array using 1 line of code
2. Manipulate the array to your liking via a UI - THIS IS THE HARD BIT
3. ? ? ?
4. Write the array back to the file using 1 line of code
It's very simple. But again, you don't respond about the UI difficulties.
Posted 13 April 2012 - 05:06 AM
Yeah I didn't remember that there is a "root array" for all the config keys. If it was a file with many different arrays it would have been more difficult.
What should be hard?
However... I think there are two approaches...
1) Simpler: json_encode config into the Db, but you can do the same thing using your approach (with the exception of possible filesystem permission issues). P.S. Thank you for the hint.
2) Harder: have a proper Db structure where every config value has its own row etc.