With several modules I collaborate on, such as Media, Media: YouTube,
Node Reference / Embed Media Browser (nrembrowser), etc, we are using a
customized version of the proposed variable API that didn't make it into d7:
http://drupalcode.org/viewvc/drupal/contributions/modules/media/includes/media.variables.inc?revision=1.11&view=markup&pathrev=MAIN
Prepends all variables with media__ (note the double underscore). Also,
by defining all definitions, allows for an easy uninstall, with:
foreach (media_variable_default() as $name => $value {
media_variable_del($name);
}
This allows modules to use similar namespacing (as the problem is not
simply going to go away). Also defines variable defaults, so that vars
are called like:
media_variable_get('file_extensions');
which is easier to deal with on many levels than
variable_get('media__file_extensions', 'jpg jpeg gif png txt doc xls pdf
ppt pps odt ods odp mp3 mov m4v mp4 mpeg avi ogg wmv ico');
and can also be overridden as usual with
media_variable_get('file_extensions', 'jpg jpeg gif png');
For updating modules from an old scheme to the new scheme, look at
http://drupalcode.org/viewvc/drupal/contributions/modules/media_brightcove/media_brightcove.install?revision=1.1.2.8.2.2&view=markup&pathrev=DRUPAL-6--2
/**
* Convert variables to the Media: Brightcove variable namespace.
*/
function media_brightcove_update_6102() {
$ret = array();
$variables = array(
'brightcove_publisher_id' => 'publisher_id',
'brightcove_player_id' => 'full_player_id',
'brightcove_player_preview' => 'preview_player_id',
'emvideo_brightcove_token' => 'read_token',
'emvideo_brightcove_write_token' => 'write_token',
);
foreach ($variables as $old_variable => $new_variable) {
_media_brightcove_migrate_variable($old_variable, $new_variable);
}
$ret[] = array('success' => TRUE, 'query' => "Converted variables to
the Media: Brightcove variable namespace.");
// Add the new settings page to the menu.
menu_rebuild();
$ret[] = array('success' => TRUE, 'query' => "Rebuilt the menu for
the new administrative settings page.");
return $ret;
}
/**
* Migrate a variable from the old namespace.
*/
function _media_brightcove_migrate_variable($old_variable, $new_variable) {
$value = variable_get($old_variable,
media_brightcove_variable_default($new_variable));
if (media_brightcove_variable_get($new_variable) != $value) {
media_brightcove_variable_set($new_variable, $value);
}
variable_del($old_variable);
}
On 10/16/2010 12:34 PM, David Cohen wrote:
Hey, I'm wondering what the community thinks about this...
I feel that if I have modules/foo/foo.module checked into drupal.org CVS
and drupal.org/project/foo, then this module stakes a claim to the
foo_... namespace. That is, I can name my functions foo_whatever
without worrying that some other module out there already defines the
same function. Similarly, I can name my variables foo_whatever,
database tables, and so on.
Now, let's say someone else checks in a module called foo_bar. And say
both modules define the same function, variable or other namespace
collision. What then? Is that a bug, and if so which module is
responsible for fixing it?
If you want a concrete example, both fb.module and fb_social.module
define variables starting with "fb_", and specifically I wonder how to
respond to http://drupal.org/node/943462.
I don't want to start a flame war. I'm curious if there is community
consensus or official policy. Personally I think its a bad idea to name
any module with an underscore. That is, drupal.org/project/foo_bar
should instead be drupal.org/project/foobar, as this avoids any
confusion.
-Dave
--
Aaron Winborn
Advomatic, LLC
http://advomatic.com/
Drupal Multimedia available in September!
http://www.packtpub.com/create-multimedia-website-with-drupal/book
My blog:
http://aaronwinborn.com/
