[development] low hanging fruit for Drupal 6: variable?defaults

Larry Garfield larry at garfieldtech.com
Fri May 4 17:46:01 UTC 2007

On Fri, 4 May 2007 19:50:34 +0300, Mohammed Sameer <msameer at foolab.org> wrote:

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

I think that's over-engineering.  While node types are the most common "variable variable", there's lots of others.  captcha.module uses form ids.  Some modules could even use node ids (although that would probably be rather silly).  I don't think locking it down to a specific type of entity would be a good idea, as it would either create a crapload of different entity types or block us from using certain types, or both.

--Larry Garfield

More information about the development mailing list