Как лучше всего для расширения Firefox избежать загрязнения глобального пространства имен?

Я читал о загрязнении глобального пространства имен при разработке расширения для Firefox, и я хочу по возможности избежать этого в своем расширении. Есть несколько решений, но, как правило, решения, похоже, сосредоточены только на объявлении одной глобальной переменной для вашего расширения и помещении в нее всего. Таким образом, вы добавляете только одну дополнительную переменную в глобальное пространство имен, что не так уж и плохо.

Вкратце, мне было предложено решение, которое позволяет избежать помещения любых дополнительных переменных в глобальное пространство имен; оберните все в функцию. Проблема здесь в том, что в ваших наложениях XUL не на что ссылаться. Вы должны объявить элементы в ваших наложениях, а затем в JS добавить тонну addEventListener , чтобы заменить что-то вроде oncommand = "..." в XUL . Я не хочу этого делать; Я определенно хочу, чтобы мой XUL включал события в сам XUL, потому что я думаю, что он выглядит чище, поэтому это не решение для меня. Поэтому мне нужна как минимум одна глобальная переменная для атрибутов XUL oncommand = "..." , на которые можно ссылаться.

Итак, консенсус, похоже, состоит в том, чтобы иметь одну (и только одну) переменную для вашего расширения, и поместите в него весь свой код. Проблема вот в чем: обычно люди рекомендуют называть эту переменную красивым длинным и уникальным именем, чтобы иметь почти нулевую вероятность столкновения с другими переменными. Итак, если идентификатор моего расширения (скрыт), я могу назвать свою переменную myextensionAtMycompanyDotCom или com.mycompany.myextension . Это хорошо для предотвращения коллизий в глобальном пространстве имен, но есть одна проблема; это имя переменной длинное и громоздкое. Мой XUL будет завален ссылками на обработчики событий типа oncommand = "myextensionAtMycompanyDotCom.doSomeEvent" . Невозможно избежать ссылки на глобальное пространство имен в моих наложениях XUL, потому что наложение просто добавляется в DOM окна браузера; у него нет собственного пространства имен, поэтому мы не можем каким-либо образом ограничить область видимости переменной нашего расширения только нашими собственными наложениями. Итак, на мой взгляд, есть четыре решения:

1. Просто используйте длинное имя переменной в XUL

. Это приводит к довольно громоздкому и подробному коду XUL, например:

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

2. Добавьте элемент случайности к короткому имени переменной

Мы придумали гораздо более красивое короткое имя переменной для нашего расширения, скажем myExt , и добавим несколько случайных символов, чтобы сделать его почти наверняка уникальным, например myExtAX8T9 . Затем в XUL мы имеем:

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

Очевидно, это приводит к довольно уродливому и даже запутанному коду, поскольку случайные символы выглядят странно и делают их похожими на какую-то временную переменную.

3. Не объявляйте никаких глобальных переменных вообще

Вы можете просто обернуть все в функции. Это, конечно, означает, что в вашем XUL не на что ссылаться, и поэтому каждое событие должно быть прикреплено к элементам XUL с помощью addEventListener в вашем коде JavaScript. Мне не нравится это решение, потому что, как упоминалось выше, я считаю, что проще иметь ссылки на события в коде XUL, чем искать тонны кода JS, чтобы найти, какие события к каким элементам XUL привязаны.

4. Просто используйте короткое имя переменной в XUL

. Я мог бы просто вызвать переменную своего расширения myExt , и тогда я получил бы хороший код XUL, например:

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

Конечно, это короткое имя гораздо чаще будет конфликтовать с чем-то еще в глобальном пространстве имен, и это не идеально.

Итак, я что-то пропустил? Есть ли альтернатива четырем решениям, которые я предложил выше? Если нет, то что было бы лучшим из 4 (учитывая, что № 3 в принципе неприемлем для меня) и почему?

6
задан Jez 13 July 2011 в 09:43
поделиться