Using Constants For Permission Names: WHY?
Submitted by joachim.noreiko on Wed, 30/06/2010 - 15:19
I keep seeing this sort of thing in so many modules:
define("MY_MODULE_PERM_ACCESS_WIDGETS", 'access widgets');
// Names changed to protect the guilty ;)Am I missing something, or is this utterly pointless?
The only advantage I see is that you can change the permission string later on. But you actually can't change a permission string once you've made a release without an almighty amount of work in a hook_update_N()[*] to migrate users' existing permissions, so what is the point of using a constant apart from just creating shouty caps noise?
[*] Is there a helper function in core yet for migrating permission names during updates? There really should be.
Autocomplete in IDEs?
Autocomplete in IDEs?
IDEs
IDEs provide autocomplete for these permission names, so people do use it. Unfortunately this makes hook_perm() non-parseable by the localization server / potx, so it makes your permission names hidden from pre-translation. The translation template extractor module does alert you of this fact if you do use it to check your module for API compatibility.
I don't know the exact
I don't know the exact problem with permission names in drupal, but I think constants are good when you build bigger systems.
They help you to separate data from logic.
By using constants, you tell the readers of the code that this value has a special meaning.
And as extra bonus it helps to separate which strings to translate and which not.
And you can use constants even when you not plan to change them, that is why they are called constants :-)
Even if using constants might
Even if using constants might be visually daunting, I think it might help keeping the code DRY and avoid (worrying about) stupid typing errors such as "aceess content" vs "access content".
constants help in debugging
Using constants helps me to prevent typos, and IDEs help me to use the correct constant names. That's all, and this is a great advantage for me.
Regards,
Péter
Good Practice
Generally speaking avoiding literals in code is good practice, the ability to change the values is one factor.
While in this instance the value is hard to change, using constants is a good habit to get into.
The main advantage I'd see here is that PHP can generate an error message if you use a constant that isn't defined.
Also most IDEs will auto-complete constant names, and if you always start constant names for perms with MYMODULE_ACCESS_ this helps you type the start of the constant and have auto-complete remind you what perms you've already created.
If you just use literals everywhere it's all to easy to end up with a bug caused by two perm strings that are unintentionally different.
Typo prevention
Permission typo's are silent errors (eg 'adminster site configuration'); using constants gives you autocomplete in certain IDE's and warnings when you make a mistake.
<?php/** * Updates
<?php/**
* Updates permissions after the name of a permission changed.
*
* @param $old
* The name of the old permission.
* @param $new
* The name of the new permission.
*/
function MYMODULE_update_permission($old, $new) {
$sql = "UPDATE {permission} SET perm = '%s' WHERE pid = %d";
$result = db_query("SELECT pid, perm FROM {permission}");
while ($r = db_fetch_object($result)) {
$perms = explode(', ', $r->perm);
$key = array_search($old, $perms);
if ($key !== FALSE) {
$perms[$key] = $new;
db_query($sql, implode(', ', $perms), $r->pid);
}
}
}
?>
The only development
The only development advantage, other than as you point out leaving the precise string open to easier change during development, is that PHP will warn if you use an undefined constant, so any weird bugs from a minor mistake in the permission name are avoided.
But this does go against recommended coding style and doesn't seem a good enough reason not to simply be careful with our strings!
define
I started using define for variable_get.
<?phpdefine("MY_MODULE_SETTING", FALSE);
variable_get('my_module_setting', MY_MODULE_SETTING);
?>
This allows me to change the default variable_get without having to change the default in multiple locations if you use variable_get in multiple places. Only drawback is define will not take an array so you can't use it for all settings one might use with the forms api system_settings_form combo.
Me too
This is useful.
safety for dev?
some folks prefer to type constants instead of strings because and IDE helps complete them and if you typo, php throws a warning. It can be a nasty silent bug when you mistype a perm name in your code. i don't do this, but i can see the benefits.
If you are using an IDE that
If you are using an IDE that will let you auto-complete and/or warn you when you use undefined constants it can help you avoid typos in the permission name.
I guess the main reason is
I guess the main reason is that you will see a notice when you have a typo in the permission name but I don't like it either. Replacing a string is just as easy as replacing a constant....
Also, since Drupal 7 does not display the technical permission name anymore, but only a configurable title and optionally a description, that makes improving permission "names" easier as long as you just change the user facing texts.
To prevent bugs due to typos.
To prevent permission bugs due to typos in the repeating of the string. PHP will complain when there's a typo, i.e. when you're trying to use an undefined define.
Ease of development
My guess: it makes life easier for developers working with any kind of IDE. Rather than finding the permission to copy and paste it when they need to use it again, most will be able to use the IDE's auto-complete to quickly type the define name. It also reduces the possibility of mis-typing the permission somewhere: if they mis-type the define name, they'll get a notice from PHP warning that they're trying to use an undefined var.
[*]
The rather excellent Secure Permissions module helps circumvent the issue of updating permissions - makes it much less painful:
http://drupal.org/project/secure_permissions
Post new comment