[development] DEP - cascading variable system

[Zack Rosen]

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?

-Zack

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  
> 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
>
>
>