【问题标题】:Firefox extension JSMs and namespace ettiquiteFirefox 扩展 JSM 和命名空间礼仪
【发布时间】:2011-04-30 16:37:58
【问题描述】:

因此,在 Firefox 扩展中,鼓励扩展的对象存在于 com.contoso.myExtension 等子对象中。这样,您就没有将任何对象放在全局命名空间中,并且扩展通常不会互相影响。 (至少在常见的 browser.xul 窗口中)

但根据我对Javascript code modules (JSMs) 的了解,虽然模块本身在单独的命名空间中工作,但它导出的符号最终会出现在导入它的任何代码的全局命名空间中。此外,扩展不可能是“好的”并且只尝试构建子对象;这些导出的符号只会破坏已经存在的任何全局变量。您也不能导出像 com.contoso.myExtension 这样的符号。它只是一个简单的全局变量。

那么在使用 JSM 时,什么是玩得好的协议呢?只是制作很长的变量名并希望它们不会发生冲突?

【问题讨论】:

  • 我喜欢新的jsm标签!

标签: javascript firefox-addon jsm


【解决方案1】:

首先,我还没有看到一个真正的标准来处理这个问题。但我们绝对可以做得比长变量名更好...

您对生活在单独的 命名空间 中的 Javascript 代码模块(可以这么说)是正确的,但是当您导入它们时,您不必将它们导入全局命名空间。如果您查看Components.utils.import 文档,您会看到可以导入到特定范围。也就是说,您根本不必污染全局命名空间

您可以将模块收集到 myExtension 命名空间中。

var myExtension = {};
Components.utils.import("resource://.../module.jsm", myExtension);

将其包装在一个自执行函数中不会让任何变量泄漏到全局命名空间中,甚至myExtension

(function(){
    var myExtension = {};
    Components.utils.import("resource://.../module.jsm", myExtension);
})();

【讨论】:

  • 太棒了。我认为导入到 com.contoso.myExtension 会很好。您只需在扩展的命名空间中获得更多对象。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-12-05
  • 1970-01-01
  • 2014-09-18
  • 2011-06-28
  • 1970-01-01
  • 2017-11-24
相关资源
最近更新 更多