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

Wim Leers bashratthesneaky at gmail.com
Thu May 3 10:23:59 UTC 2007


Gabor, obviously you're right. I hadn't thought of that immediately,  
the first example use case was just wrong. But my second example /is/  
valid. I'll explain it properly now:

1) On the settings page, you have some select form item, with the  
multiple attribute set to true. You set the default to 0, -1,  
whatever. Whatever the user chooses, the result is stored as an /array/.

2) In your actual code, you set the default to NULL. This is  
necessary, because the foreach you want to use requires an array and  
not a scalar. So 0, -1, or whatever you used on the settings page,  
cannot be used here. NULL equals a non-existing array and thus the  
foreach will stop execution right away.

Now, this example makes a lot more sense, I hope :P Note that you  
don't need any submit or validate handlers in this example, thus zero  
lines of additional code.

Wim

On May 3, 2007, at 12:13 , Gabor Hojtsy wrote:

> Wim, you said this is cool, because you don't need to check for an  
> empty string, but you would set the default to an empty string for  
> the settings form. So when the user saves the setting form, you get  
> an empty string back from variable_get(), which would show you the  
> error you skipped to check for because you use NULL as a default  
> there. Once the user saves the setting, you can have any number of  
> different default, you will always get the value the user saved.
>
> Well, if you mangle with the variable after being submitted from  
> the form, and before being saved (which you did not mention  
> before), it means that you write more code where the form  
> processing takes place (instead of reusing the built in Drupal  
> settings form saver). That moves your code from one place to the  
> other. And you will also need to code around the saving of the  
> localized variables later once we have that included in Drupal.
>
> I am fine with having this supported, in case this seems to be  
> making your life easier, although I don't agree that this is easier  
> then not mangling with variable values.
>
> Gabor
>
> Wim Leers wrote:
>> I personally see this as a viable use case, yes. It saves me  
>> another if-test. But my example wasn't quite accurate. Suppose you  
>> have a multiple select form item. You set the default to -1 for  
>> the settings page, and /then/ to NULL in your code. But probably  
>> you already figured that yourself.
>> I don't see how exactly this breaks my code? It doesn't break  
>> anything, it's pure convenience.
>> Wim
>> On May 3, 2007, at 11:57 , Gabor Hojtsy wrote:
>>> Wim Leers wrote:
>>>> One use case is: on the settings page you set the default to a  
>>>> certain value, for example an empty string. But elsewhere in  
>>>> your code, you set the default to NULL, because then you can  
>>>> just do:
>>>>     $var = variable_get('some_var', NULL);
>>>>     foreach ($var as $key => $value) { ..}
>>>> without having to check if $var is the empty string. Because  
>>>> using NULL will immediately end the foreach loop and an empty  
>>>> string would generate an error.
>>>> Simple use case, but again a bit shorter!
>>>> I'll do this one :)
>>>
>>> So you break your code once the user saves the settings page. Do  
>>> you present this as a viable use case?
>>>
>>> Gabor
>



More information about the development mailing list