What is the best way to use the Firefox extension so as not to pollute the global namespace?

Question

I read about global pollution of the namespace when developing an extension for Firefox, and I want to avoid its extension as much as possible. There are several solutions, but usually the solutions seem to be centered around declaring only one global variable for your extension and nesting. This way you add only one extra variable to the global namespace, which is not so bad.

In short, I had a solution offered to me that avoids adding any additional variables to the global namespace; wrap everything in a function. The problem here is that there is nothing to refer to in your XUL olexes. You have to declare the elements in your overlays and then add a ton of addEventListener in JS to replace what would look like oncommand="..." in XUL. I do not want to do this; I definitely want my XUL to include events in XUL itself, because I think it looks cleaner, so this is not a solution for me. So I need at least 1 global variable for the XUL attributes oncommand="..." for reference.

So consensus seems to have one (and only one) variable for your extension and put all your code in it. Here's the problem: usually people recommend that this variable be called a beautiful long unique name to have an almost zero chance of colliding with other variables. Therefore, if my extension identifier is [e-mail] , I can name my variable myextensionAtMycompanyDotCom or com.mycompany.myextension . This is useful for preventing collisions in the global namespace, but there is one problem; this variable name is long and bulky. My XUL will be dotted with links to event handlers on the lines oncommand="myextensionAtMycompanyDotCom.doSomeEvent" . There is no way to avoid having to reference the global namespace in my XUL overlay, because the overlay is simply added to the browser DOM window; it does not have its own namespace, so we cannot somehow limit the scope of the extension to our own overlays alone. So, as I see it, there are four solutions:

1. Just use the long variable name in XUL

This leads to a rather cumbersome verbose XUL code, for example:

 <statusbarpanel id="myStatusBar" onmousedown="myextensionAtMycompanyDotCom.onMyStatusBarClick();"> 

2. Add a random element to the short variable name

We came up with a much myExt short variable name for our extension, say myExt and add some random characters to make it almost certainly unique, like myExtAX8T9 . Then in XUL we have:

 <statusbarpanel id="myStatusBar" onmousedown="myExtAX8T9.onMyStatusBarClick();"> 

Clearly, this leads to a rather ugly and even confusing code, as random characters look weird and make it look like a temporary variable.

3. Do not declare any global variables at all

You can simply complete all functions. This, of course, means that there is nothing to mention in XUL, so every event should be bound to XUL elements using addEventListener in your JavaScript code. I don't like this solution because, as mentioned above, I think it is cleaner to have the events referenced in the XUL code, rather than looking for a ton of JS code to determine which events are associated with the XUL elements.

4. Just use the short variable name in XUL

I could just call my myExt extension variable and then get some nice XUL code, like this:

 <statusbarpanel id="myStatusBar" onmousedown="myExt.onMyStatusBarClick();"> 

Of course, this short name is much more likely to encounter something else in the global namespace and is therefore not ideal.

So, am I missing something? Is there an alternative 4 to the solutions suggested above? If not, what would be the best of 4 (given that No. 3 is basically unacceptable to me) and why?

Answer 1

We use the JavaScript module template described in this blog post: http://www.adequatelygood.com/2010/3/JavaScript-Module-Pattern-In-Depth . You can export the characters you want to use in XUL handlers as described.

In addition, we use the return host name as the module name prefix to ensure that we manage the namespace:

 /* Set up the global namespace. */ if (typeof(com) == "undefined") var com = {}; if (!com.salsitasoft) com.salsitasoft = {}; /* Main namespace. */ com.salsitasoft.myExtensionGlobalStuffGoesHere = (function (my) { return my; })(com.salsitasoft.myExtensionGlobalStuffGoesHere || {}); 

Update: I changed this to pass com.salsitasoft.myExtensionGlobalStuffGoesHere to close, if it already exists, so that the namespace can be extended to multiple files.

Answer 2

Your functions must "live" somewhere anywhere, so you can’t avoid pretending to be a namespace. I also agree that defining an event in XUL is better than attaching. So, I suggest a hybrid between 3 + 4:

• Find a namespace that is unique to your plugin, but as memorable as possible, such as "catchyseo".

• Put all the code of your plugin and all the variables inside this namespace. Use an anonymous function shell template, for example (look at some jQuery plugins as code examples):

   window.catchyseo = (function(){var private = x; [...] })(); 

• In your namespace, output some event handlers that you can reference in your XUL.

This approach gives you the best of two worlds: you can define your events in XUL, and you have a closed namespace without any global pollution of the namespace except for one namespace variable.