[development] Cascading variable system

[Adrian Rossouw]

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