On 30 Nov 2005, at 2:00 AM, Zack Rosen wrote:
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. We already do this for all user specific settings (like whether or not tinymce is enabled.)
* What in the heck is the user interface going to look like for managing different sets of settings?
(i'll add this to the bottom) User interface doesn't change, only the flexibility of where saved settings take effect is added. So instead of saving settings to the data column in the user table, or stuffing all of the theme specific settings in a single variable, we store them in a nice normalised table. You would set variables using function variable_set($variable, $value, $domain = null, $id = null) { and you would get variable using function variable_set($variable, $default, $domain = null, $id = null) { The code specified default would go to the bottom of the queue, followed by the defaults the install profile specified (install profiles need this. otherwise any default setting change involves changing code wherever it happens) followed by the system wide settings, followed by the layout/section/ theme specific settings (this is the next DEP I want to write) and then at the very top of the stacks, the system overrides (like when a hosting provider doesn't want people to touch the files dir) [5] $GLOBALS['override'] [4] user settings. system table, user domain, userid key. [3] theme settings. system table, theme domain, theme name key. [2] system settings. system table, system domain. [1] $GLOBALS['defaults'] [0] $default -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com