扩展开发基础

hechengjin

安装的扩展程序是一种以 XPI（Cross-PlatformInstaller Module） 做为其扩展名的文件，实际上它只是一个 ZIP 格式的文件，扩展名不同而矣。在下图中，显示了一个标准的扩展包括的文件和文件的目录结构。

相关目录介绍：

• chrome：必须具备的目录。此文件中保存着完成扩展主要功能的文件。
• components：可选目录，用于存放自定义的 XPCOM 组件文件。由于大多数的扩展根本没必要自己定义     XPCOM 组件，因此，在没有自定义     XPCOM 组件的情况下，此目录是不用存在的；
• defaults：负责存放一些默认的设置数据，其下还会包含子目录，以分别对默认数据进行存储；
• install.rdf：它是一个 RDF/XML 格式的文件，用于描述当前扩展的注册信息和附加信息等。扩展在安装时，负责安装扩展的程序会自动分析此文件的信息，然后将这些信息注册到系统下。此文件必须被命名为     install.rdf，并置于扩展压缩包的顶级目录下；
• chrome.manifest：负责将扩展的各种包注册到chrome     系统中。
  

1. content注册指令

用来注册一个 content 类型的包，如下：

content packagename uri/to/files/[flags]

packagename 是所注册的包名称，同 chrome 地址中的 <package name>

uri/to/files/ 用来指明这个包资源的操作系统路径，它的格式比较多。

content demoex chrome/content/

2. locale注册指令

用来注册一个 locale 类型的包，格式如下：

locale packagename localenameuri/to/files/ [flags]

localename 用来指明所注册的语言类型，如: en-US，zh-CN 等，其它的同上。

locale demoex zh-CN chrome/locale/zh-CN/

locale demoex en-USchrome/locale/en-US/

3. skin注册指令

用来注册一个 skin 类型的包，格式如下：

skin packagename skinnameuri/to/files/ [flags]

skinname 用来指明所注册的皮肤包类型，如: classic/1.0，其它的同上。

skin demoex classic/1.0chrome/skin/

4.overlay注册指令

它用来指明 XUL 的“覆盖”规则。

overlay chrome://URI-to-overlaychrome://overlay-URI [flags]

overlay chrome://messenger/content/messenger.xul chrome://mintrayr/content/messenger/messenger.xul

5.style注册指令

它用来指明 CSS 的“覆盖”规则，这是新加入的特性。通过这个新规则你可以为已有的界面文件引入新的样式表效果。

style chrome://URI-to-stylechrome://stylesheet-URI

style  chrome://messenger/content/messenger.xulchrome://demoex/skin/masterpasswordplus.css

6.override注册指令

在某些时候，你可能会有完全“重载”或者说是替换某个 chrome 文件的要求，这条指令就可以完成这种要求。

overridechrome://package/type/original-uri.whatever new-resolved-URI

override chrome://mintrayr-icon/skin/appicon64.pngchrome://branding/content/icon64.png

override chrome://mintrayr/skin/common.csschrome://mintrayr/skin/common-fx4.cssapplication={ec8030f7-c20a-464f-9b0e-13a3a9e97384} appversion>=4.0b7os=winnt

扩展的二级结构

• content：用于存储负责描述扩展界面的 XUL 文件和完成实际逻辑功能的 JS 文件；
• locale：用于存储负责本地化处理的字符串数据文件，这些文件中的本地化字符串内容会被     content 目录中的文件所引用。如果某个扩展没有对本地化进行处理，那么它是可以省略的；
  

skin：用于存储负责美化界面外观的样式表文件和图片文件，这些文件中的样式和图片会被content 目录中的文件所引用。如果扩展没有使用单独的样式表文件和图片，那么它也是可以被省略的；

hechengjin

chrome.manifest：负责将扩展的各种包注册到FireMail     的 chrome 系统中。Gecko     1.8 内核新引入的机制，用来代替原有的 contents.rdf 文件；

hechengjin

Chrome URL
像已有的其它 URL 协议一样，我们可以通过 chrome:// 这种形式的 URL 协议来访问那些 chrome 提供者（换句话说，就是已经注册在 chrome 系统下的资源）。其实，那些资源是以物理文件或目录方式被存储，通过地址映射机制以 chrome 地址来访问的。但是我们根本不用管其物理地址是什么，Mozilla 下的扩展及其自身都是以这种映射过的地址来访问的。这样做的最大好处就是屏蔽了文件系统的多样性，为 Mozilla 的跨平台运行打下了基础。同 http 和 ftp 地址格式不一样，Mozilla 对 chrome 地址格式做了严格的规定，如下：
chrome://<package name>/<part>/<file.name><package name> 用来指明访问的扩展名称


它的 <package name> 在contents.rdf 文件或chrome.manifest文件中被定义
contents.rdf 文件中被定义，或是被 chrome.manifest 文件所定义。比如，下面的 contents.rdf 文件内容
<RDF:Seq about="urn:mozilla:package:root">  <RDF:li resource="urn:mozilla:package:sampleext“/></RDF:Seq>
它的 <package name> 是 sampleext。
你同样会在 chrome.manifest 文件中看到类似的 <package name> 命名。
content demoex chrome/content/

<part> 用来指明访问的 chrome 包类型，它分别允许 content，locale 和 skin 这3 种固定的类型。
<file.name> 用来指明访问的文件名称，因为前面的 <package name> 和 <part> 已经对文件的路径做了限定，所以，这个文件相对来说是某个明确的文件。