[development] DEP - cascading variable system

[Adrian Rossouw]

This is my first attempt at writing something like this, to me it's  
not as much about creating a useful DEP out of this, as it is
getting a working format going.  I apologise for having left this so  
long, it's been in my drafts for week now. I am just sending
the incomplete document to see where we can go from.

If you have any other suggestions, please make them. I'd like to keep  
the format as simple as possible.

Title : Cascading variable system.
Abstract: This DEP defines a method to allow for more flexibility in  
the way we handle variables.
Author: Adrian Rossouw
Dependencies: None
Repository: Core
Status: Suggestion?

1. Introduction :
This DEP specifies a way to clear up and centralise the variable  
system in Drupal, and hopefully abstracts some code that
we are often using for specific cases.

2. Motivation :
Variables in Drupal ( records in the variable table ), are primarily  
used to store settings for the site.
Frequently however, we have the need to override the specified variable.

Two such cases are
   a. variables that can be overridden for each user (the theme  
setting, for instance)
   b. variables that can be overridden for each theme (such as  
whether or not to display the site title).

This is done to allow us to specify defaults for the site, and then  
allow these defaults to be altered.
In the case of (a.), we manually test for the overridden value with  
each occurence of the variable, and
in the case of (b.) we have centralised all the theme variable  
changes by introducing the theme_get_variable()
function.

This has the benefit of allowing us to define even more layers of  
variables, such as .. blog specific settings,
node specific settings,  locale specific settings (allowing us to  
localise the variables like site_name etc.)
and even install specific settings (so install profiles can provide  
default values for the system).
Additionally, it allows host administrators to specify system wide  
overrides. variables that an administrator
can define as non-changeable (the files path, for instance)

3. Approach :
This DEP proposes that we add 2 columns to the variable table, namely  
'domain' and 'key'.

This extra information would be used to store data against a certain  
object. In the case of the user system
saving variables, it would save the variable with 'user' as the  
domain and $user->uid as the key. In the case
of themes, it would save the variable with 'theme' as the domain and  
the theme name as the key.

By default, only the system wide settings would be loaded, and then  
each module that wants to add a new
layer to the variable stack, can add it's own layer of settings. (ie:  
user module will load all the settings
related to the user).

The only variables that will actually be overridden are variables  
that an explicit interface element is defined
for, and the only variables that will be saved are the ones that  
differ from the original variables.




--
Adrian Rossouw
Drupal developer and Bryght Guy
http://drupal.org | http://bryght.com