[development] DEP - cascading variable system
zacker at skylinepublicworks.com
Wed Nov 30 00:00:36 UTC 2005
This is a very cool idea Adrian. I have a few questions...
* Other than the theme_get_variable function is there other code this
helps you abstract?
* Do you got good ideas of use cases where different users want
different settings variables? I definitely see the coolness of
letting people have different configs for their blog / organic
groups, but not quite getting the advantage of letting users
configure the site to their own preference.
* What in the heck is the user interface going to look like for
managing different sets of settings?
On Nov 29, 2005, at 1:59 PM, Adrian Rossouw wrote:
> 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
> 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.
> Adrian Rossouw
> Drupal developer and Bryght Guy
> http://drupal.org | http://bryght.com
More information about the development