[development] DEP - cascading variable system
adrian at bryght.com
Tue Nov 29 21:59:17 UTC 2005
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
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()
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.
Drupal developer and Bryght Guy
http://drupal.org | http://bryght.com
More information about the development