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