On Fri, May 04, 2007 at 09:26:44AM -0500, Larry Garfield wrote:
On Friday 04 May 2007, Dries Buytaert wrote:
Anyway, let's step back for a bit. It seems like we're trying to solve two problems in this thread:
1. For convenience, we want a central place to define a variable's default value.
2. Out of necessity, we want a mechanism to let the locale system translate variables that have dynamic content shown on the UIs (i.e. the footer message).
1 and 2 are somewhat related -- if we had a mechanism to introspect what variables are available, we might be able to extract their default value from a central place, and the locale system could figure out what variables need to be translated.
So, each variable should have two properties: (i) a default value and (2) a "dynamic translation"-flag (TRUE if translatable, FALSE if not) and we should be able to poll both. Gabor's original question was: what would be the best implementation?
Because the variables could change at runtime, I think a hook_variables() (or similar) would be the best approach. Core may not use more than just node type, but I know some contribs do, like form IDs.
hook_variables() { $items = array(); $items['mymod_num_things'] = array( '#default_value' => 2, // Same syntax as FAPI uses '#realm' => 'mymod', // optional '#translatable' => FALSE, // probably default false '#cacheable' => TRUE, // default to TRUE if under X chars when serialized '#serialize' => FALSE, // default to true for object/array, else false ); foreach (node_get_types('name') as $type) { $items['mymod_things_for_' . $type] = array( '#default_value' => array(), ); }
return $items; }
I kinda like the idea of using FAPI syntax here, as then system_settings_form() can fill in defaults for us if they're not specified. (I suppose it could anyway, but meh. <g>) I leave that to Gabor to decide.
I'm undecided on whether non-cached big variables should still be considered variables or should have some other namespace/table. I guess that depends on how expensive it would be to make variable_get() handle both cases.
I'd actually declare it as hook_variables($type, $arg2) The module will not always know about the available node types as we can add a bunch after enabling the module. So I'd say that whenever we have a new content type (No idea how to detect that) we call this hook to update our defaults. The problem is that hook_variables() returns the default related to the node types we have as well as the defaults not related to the node types. That's why $type can either by 'node' for node types related defaults, 'comment' for comments related settings, 'term' for term related, 'vocabulary' for vocabulary related and 'default' for anything else ? Or would this be an over kill ? -- GPG-Key: 0xA3FD0DF7 - 9F73 032E EAC9 F7AD 951F 280E CB66 8E29 A3FD 0DF7 Debian User and Developer. Homepage: www.foolab.org