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

[Mohammed Sameer]

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