With the recent system configuration / data discussion going on, I thought perhaps I should dredge up this again : http://lists.drupal.org/archives/development/2005-11/msg00882.html Basic outline : Instead of using just 'name' as a key, add additional 'realm' and 'key' columns, which can then be used to build a layered set of variables. During initialisation, every module / system has the opportunity to load it's variables into the tree. For example : variable_init('system'); /// would load the basic system variables variable_init('theme', $GLOBALS['theme']); // would load theme specific settings. onto the stack. variable_init('user', $GLOBALS['user']->uid); // would load user specific settings. onto the stack. Basically this would allow us to do all kind of variable overriding, and could even be extended to use separate tables for each realm. To set a variable, you would still just use variable_set('variable', 'value'); // doesn't break anything that works now or to set it for a specific realm (like on the user profile edit page) : variable_set('variable', 'value', 'user', $edit['uid']); // set the variable for that specific user. This could also be extended to provide the following hard coded realms for install profiles and system administrators (and this is important) [top level] system wide overrides. Hard coded by the system maintainer in the settings.php [3] theme specific [2] user specific [1] system settings [0] install profile wide defaults [ hard coded by the install profile. this allows the 'reset to defaults' to not mess up the site] [-1] The default provided in the variable_get function. Only use this when nothing else is available. You would also need a function to switch around the order the variables are resolved in (for those wondering about expensive for loops, it should get collapsed with array_merge, so the lookups are only against one thing.) What is neat about this method, is modules could add in their own levels , such as node specific configuration , which extends to og specific configuration .. etc. I would also like to see this extended to the point that system wide overrides get disabled in the admin section. So that admins can't muck up things they shouldn't be able to change. (files dir). -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
I like this system and perhaps we could solve an old gripe that I have about our current variables; that many variables never get initialized but rather remain undocumented 'features' of the code. IMO, it is bad form if you have variable_get('foo', 'baz') and can't find variable 'foo' in the database. All vars should get initialized. -Robert Adrian Rossouw wrote:
During initialisation, every module / system has the opportunity to load it's variables into the tree. For example :
I like this system too. Realm can be anything. For example, contrib modules can each have their own realm. Allie also supports this approach from the old thread. +1
On 12 Jun 2006, at 3:46 PM, Khalid B wrote:
Realm can be anything. For example, contrib modules can each have their own realm.
And the theme configuration module i mentioned earlier is why this came up in the first place. So each theme can be completely individualised. (note, that i believe the block table needs to have realm and id fields too probably) -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
I was half a click away from saying this sounded familiar before I reread the Adrian's original post and realizing it was a revisit. I liked the idea before and still do. +1 It would also seem you could also get some performance boosts by doing some lazy loading and only load the realms used on a page. It should decrease the memory footprint return smaller data sets from the database etc. It would probably be a minor benefit but very helpful in larger sites. James Gilliland
participants (4)
-
Adrian Rossouw -
James Gilliland -
Khalid B -
Robert Douglass