Re: [development] low hanging fruit for Drupal 6: variable defaults
I don't think the suggestion below makes sense (setting variable defaults via hook_install), at least if we assume that the way to reset a module setting is to delete the corresponding variable. -Peter --- From: "Greg Knaddison - GVS" <Greg@GrowingVentureSolutions.com> To: development@drupal.org Date: Thu, 3 May 2007 09:03:37 -0600 Subject: Re: [development] low hanging fruit for Drupal 6: variable defaults On 5/3/07, Gabor Hojtsy <gabor@hojtsy.hu> wrote:
**We need a central place to define variable defaults**
Why can't that central place be the variable table? We could remove the second argument to variable_get and refactor some code to do the variable_set at install time which eliminates the need for the defaults in the variable_get() calls themselves.
On 03 May 2007, at 21:43, Peter Wolanin wrote:
I don't think the suggestion below makes sense (setting variable defaults via hook_install), at least if we assume that the way to reset a module setting is to delete the corresponding variable.
Setting a variable on hook_install sounds clumsy, especially when we have /dynamic/ variables of the form: variable_get($node->type ."_something", ...) You simply don't know at install time, what variables might become available later on ... -- Dries Buytaert :: http://www.buytaert.net/
Dries Buytaert wrote:
On 03 May 2007, at 21:43, Peter Wolanin wrote:
I don't think the suggestion below makes sense (setting variable defaults via hook_install), at least if we assume that the way to reset a module setting is to delete the corresponding variable.
Setting a variable on hook_install sounds clumsy, especially when we have /dynamic/ variables of the form:
variable_get($node->type ."_something", ...)
You simply don't know at install time, what variables might become available later on ...
OK, then your constants tip (quoted below) does not stand, because /dynamic/ named variables will not be able to have defaults. (Unless you have a place to run define()-s with dynamic constant names, which would be a hook run on the beginning of all page views or something, which sounds quite scary). So seems like /dynamic/ named variables rule out .install time variable saving into the database and rule out constants, what do we get to? A hook to retrieve variable defaults from? (evil grin)
How about this:
define('site_name', 'example');
function variable_get($name) { $value = db_result(db_query(...)); return $value ? $value : constant($name); }
print variable_get('site_name');
Might get us the best of both worlds? :)
Gabor
On 5/3/07, Dries Buytaert <dries.buytaert@gmail.com> wrote:
On 03 May 2007, at 21:43, Peter Wolanin wrote:
I don't think the suggestion below makes sense (setting variable defaults via hook_install), at least if we assume that the way to reset a module setting is to delete the corresponding variable.
Setting a variable on hook_install sounds clumsy, especially when we have /dynamic/ variables of the form:
variable_get($node->type ."_something", ...)
You simply don't know at install time, what variables might become available later on ...
But isn't that true whether it's in hook_install or in hook_settings or in the define mechanism that you proposed? I don't have an answer to Peter's point about resetting to defaults so I agree the approach is half baked and should probably be abandoned. Greg
Greg Knaddison - GVS wrote:
On 5/3/07, Dries Buytaert <dries.buytaert@gmail.com> wrote:
On 03 May 2007, at 21:43, Peter Wolanin wrote:
I don't think the suggestion below makes sense (setting variable defaults via hook_install), at least if we assume that the way to reset a module setting is to delete the corresponding variable.
Setting a variable on hook_install sounds clumsy, especially when we have /dynamic/ variables of the form:
variable_get($node->type ."_something", ...)
You simply don't know at install time, what variables might become available later on ...
But isn't that true whether it's in hook_install or in hook_settings or in the define mechanism that you proposed?
A hook_settings() runs at runtime (but invoked very rarely, see my last post to Ernie). A hook_settings() can grab a list of node types and return variable names based on node types.
I don't have an answer to Peter's point about resetting to defaults so I agree the approach is half baked and should probably be abandoned.
Why wouldn't you be able to remove certain variables from the DB, thus resorting to the values returned by hook_settings()? Resetting could work fine. Gabor
participants (4)
-
Dries Buytaert -
Gabor Hojtsy -
Greg Knaddison - GVS -
Peter Wolanin