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

[Dries Buytaert]

On 04 May 2007, at 00:52, Steven Wittens wrote:
>> is going to give you the constant instead of the perfectly-valid  
>> assigned value,
>> isn't it?
>
> I think Dries was more trying to illustrate a point. It is trivial  
> to change this so it doesn't suffer from this problem:
>
> function variable_get($name) {
>   $value = db_query(...);
>   return db_num_rows($value) ? db_result($value) : constant($name);
> }
>
> We've introduced such automatic linking based on naming conventions  
> elsewhere in core too (e.g. menu argument handling, form api  
> callbacks, theme functions, etc), so this idea gets a bit +1 from  
> me. I always liked the idea of centralizing your defaults like  
> this, but I hated that it didn't save you from repeating the  
> defined constant everywhere.

Unfortunately, as pointed out by Gabor, this solution doesn't fly.   
The problem is that we have dynamic variables: variable_get($node- 
 >type ."_something", ...).  A possible solution could be to no  
longer support dynamic variables.  In our running example, we'd then  
have to add a 'something' field to the node_type database table.   
However, for a number of use-cases this might be impractical.  Then  
again, it might also prevent that people abuse the variables table as  
an easy storage system.

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?

--
Dries Buytaert  ::  http://www.buytaert.net/