Discuz! Board

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 2060|回复: 1

扩展开发规范

[复制链接]

388

主题

602

帖子

2218

积分

金牌会员

Rank: 6Rank: 6

积分
2218
发表于 2015-11-15 10:27:22 | 显示全部楼层 |阅读模式
本帖最后由 hechengjin 于 2015-11-15 10:34 编辑

Firemail扩展开发(Extensiondevelopment)是基于 Mozilla 技术而实现的。Firemail做为一个“平台”,提供了大量的开发接口,具有高度的模块化和可扩展性。下面介绍下扩展开发的各种技术基础。
1.1   扩展开发所涉的技术
XUL:它是“XML 化的用户界面语言(XML User Interface Language)”的缩写,这是一种以平台无关性为目标,用来描述用户界面的语言,现在被广泛地应用于 Mozilla 平台。再有,Mozilla 本身的界面就是用 XUL 进行描述的。
CSS:它是“层叠样式表(Cascading Style Sheets)”的缩写,这是一种可以通过规则来控制 HTML/XUL/XML 等显示外观的语言。
DOM:它是“文档对象模型(Document Object Model)”的缩写,这是一个允许通过脚本来动态访问和更新 HTML/XML 文档的内容,结构和样式的接口。
XPCOM:它是“跨平台组件对象模型(Cross -platform ComponentObject Model)”的缩写,它很像微软的提出的组件模型技术,但它是跨平台的,即其运行环境可以不依赖于某种特定的操作系统平台。
XPConnect:一种将 XPCOM 与 JavaScript 连接起来的技术。该技术允许组件被脚本化,而且能够用 JavaScript 来进行组件的开发。
XBL:它是“可扩展的绑定语言 (Extensible Binding Language)”的缩写。
RDF:它是“资源定义框架(Resource Definition Framework)”的缩写。Mozilla 使用这种文件格式来保存扩展的注册信息和描述信息等。
JavaScript:由 Netsacpe 公司的 Brendan Eich 创造的一种解释型语言,它主要用来进行基于浏览器下的脚本应用开发。因为 Mozilla 内置了 JavaScript 解释器,所以使用 JavaScript 开发扩展,就成为编程语言的首选。虽然,你也可以使用 C++,Perl,Python 等进行扩展的开发,但这些语言的先天优势都明显不足。
对于扩展开发来说,必须掌握的技术有 XULCSSDOMXPCOMJavaScipt,而对于 XBLXPConnetRDF 做简单了解即可。
1.2   各种技术所负责的功能
XUL,CSS 都是用来负责控制程序的界面,一个是用来描述界面,一个用来在被描述的界面上加入一些界面效果(如:字体颜色,是否透明,边框大小等)。可以看出,它们更 多的功能是负责与用户打交道,所以用户在评价某个扩展程序的好坏时,多半会提及它的界面设计是否合理。如果想要使我们的扩展与用户交互得更合理,还需要你 对应用于桌面开发的人机交互有所了解;
DOM 主要用来为 JavaScritp 提供一个 HTML/XML 的文档操作接口,并且,它也可以用来操作 CSS。由于扩展的界面是由 XUL 定义的,而 XUL 只是 XML 的一个特殊应用,所以我们也可以通过 DOM 来对扩展界面进行“动态”操作(如:按钮的禁止与否,动态装载数据等)。同时,又有许多的文件和数据会采用 XML 进行存储和传输,所以创建和分析 XML 文档又显得尤为重要。可以看出,通过 DOM 接口,我们可以将程序的逻辑处理部分与界面表现部分有机的结合起来。
JavaScipt 是扩展开发的核心要求,它主要用来实现程序的业务逻辑描述。在很长一段时间里,大家都对 JavaScript 有着不正确的认识。直到最近一段时间,才有所改观。确切的说,JavaScipt 在扩展开发中起着粘合剂一样的功能。利用 JavaScript 开发扩展有着先天的优势,因为 Mozilla 本身除了底层部分是用 C++ 编写以外,大量的代码全部采用 JavaScript 编写。再有,由于 JavaScript 是非编译性的,所以即使你下载的是安装包程序,你仍然可以查看并修改其中的 JavaScript 源代码,这一点符合 Mozilla 的开源特性。
虽然 JavaScript 看上去很简单,但用 JavaScript 开发大型程序,却对开发人员本身提出了很高的要求。因为 JavaScript 是一种比较灵活的语言,就当前版本的 JavaScript 来说,其本身并没有提供很好的进行大型开发的结构,所以就要求开发人员必须具备很强的能力,对那些复杂的结构进行模块化的处理。如果仅仅使用面向过程进行 开发,就会在开发时“捉襟见肘”,这就要求开发人员必须采用面向对象的方式进行开发。可以说,从网页下的 JavaScript 开发到扩展下的 JavaScript 开发,是一种由轻量级到重量级的转变。
由于 JavaScript 语言只内置了几个与本地访问无关的对象,而对于桌面开发来说,显然不能满足要求。因为桌面开发需要访问大量的本地和网络资源,包括文件,剪贴板,Socket,浏览器本身等各种资源。而 XPCOM 为面向桌面的开发提供了这种可能,并且它使开发出的扩展程序可以跨平台的运行,而不用依赖于某个特殊的操作系统。只有使用 XPCOM,我们的扩展才可以做出实用的功能,没有 XPCOM,本地与远程的资源整合可以说是不可能。虽然扩展开发是用 JavaScript 来做的,但每个封装的对象或函数可能都要调用 XPCOM 对象来完成特定的功能。可以这么说,离开 XPCOM,我们寸步难行。
要想对以上的技术依次做很深入的解释简直是太难了,因为每种技术本身和它的应用都足以写上厚厚的一大本书。我现在还不打算做这么系统的工程,我打算从一个示例入手,将这个看上去很复杂的问题说得简单点儿。

1.3   扩展实现原理“覆盖”技术
“覆盖”规则原理图示

overlay.jpg
基于我们的覆盖系统技术,可实现别人定制的界面嵌入到我们的主界面中,以达到模块化功能支持。
覆盖系统十分简单,一个文档是XUL 主文档(main.xul),它提供了整个内容的入口点;另一个是文档是 XUL 覆盖文档(overlay.xul),它描述了覆盖到主文档中的内容。当这些文档被装载时,覆盖内容会被合并或者加入到主文档的内容中。但以上的这一过程只发生在内存中,所以不会影响到原始的物理文件。


第1部份    扩展的结构及 Chrome 注册
本章就扩展程序的结构和 Chrome 注册机制,予以比较详细的讲解,只有当你对这部分的内容清楚以后,才能正确的对扩展项目进行配置。
1.1   扩展程序的结构
扩展程序是一种以 XPI 做为其扩展名的文件,实际上它只是一个 ZIP 格式的文件,扩展名不同而矣。所有的扩展程序,包括上一节提到的那些扩展都具有相似的内部结构。你可下载一个现成的扩展(比如:demoex),将其扩展名改名成 ZIP,并对其解压缩,你就会看以其内部的组织结构。下面对其内部组织结构进行解释说明。
1.1.1   扩展的顶级结构
一个标准的扩展程序,解压缩后会生成以下几个目录:

  • chromeMozilla     规定扩展必须具备的目录。
  • components可选目录,用于存放自定义的     XPCOM 组件文件。由于大多数的扩展根本没必要自己定义 XPCOM 组件,因此,在没有自定义 XPCOM 组件的情况下,此目录是不用存在的;
  • defaults负责存放一些默认的设置数据,其下还会包含子目录,以分别对默认数据进行存储;
另外,其下一般还会具备 2 个特殊的文件:

  • install.rdf它是一个     RDF/XML 格式的文件,用于描述当前扩展的注册信息和附加信息等。扩展在安装时,负责安装扩展的程序会自动分析此文件的信息,然后将这些信息注册到 ThinkMail 系统下。此文件必须被命名为 install.rdf,并置于扩展压缩包的顶级目录下;
  • chrome.manifest负责将扩展的各种包注册到 ThinkMail      chrome 系统中。
如果你在别人编写的扩展中看到了除此之外的其它目录和文件,这应该是扩展开发者的一种个人行为,而不是必须的。

1.1.2   扩展的二级结构
chrome 目录下一般有以下 3 个目录。

  • content用于存储负责描述扩展界面的     XUL 文件和完成实际逻辑功能的 JS 文件;
  • locale用于存储负责本地化处理的字符串数据文件,这些文件中的本地化字符串内容会被 content 目录中的文件所引用。如果某个扩展没有对本地化进行处理,那么它是可以省略的;
  • skin用于存储负责美化界面外观的样式表文件和图片文件,这些文件中的样式和图片会被 content 目录中的文件所引用。如果扩展没有使用单独的样式表文件和图片,那么它也是可以被省略的;
下面我们再来看一下这些目录下的所存储的内容:

  • content目录下可能还会包含一个与扩展名称相同或相近的子目录,用这个子目录来存储以上提到的界面和代码文件。对于 locale      skin 目录,你可能也会看到再包含一个与扩展同名的子目录的规则;
  • locale目录下还会有针对不同语言的子目录,这些子目录会被起成如“en-US,“zh-CN这种用来区分“语言-国家/地区 的名称。通过这种国际上标准的语言区分方式,ThinkMail 会根据其自身的语言,选择一个最合适的语言目录让 content 中的文件进行引用。这样做的结果就是,同一个扩展,在编写了不同的语言包之后,它会根据 ThinkMail的语言来进行自适应。
  • skin目录下还会有针对不同的 ThinkMail主题命名的目录,如“classic,“modern等。不过,一般情况下,我们只创建针对 classic 的“皮肤。皮肤的适应方式与语言一样的,ThinkMail会根据当前的主题样式来选择一种最适合它的皮肤。
上面提到的这些目录让 ThinkMail的扩展组织结构显示得十分“冗余而复杂”。其实,这种看上去效率不高的组织方式却十分利于扩展程序的维护和降低耦合度。

1.2   install.rdf 文件
  1. install.rdf 文件位于扩展的顶级目录下,用于描述当前扩展的作者信息,升级地址,设置入口,版本兼容信息等。在安装扩展时,ThinkMail 会分析其中的信息。它的标准格式如下:
  2. <?xml version="1.0"?>
  3. <RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  4.      xmlns:em="http://www.mozilla.org/2004/em-rdf#">

  5.     <Description about="urn:mozilla:install-manifest">
  6.         <em:id>{XXXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}</em:id>
  7.         <em:name>Sample Extension</em:name>
  8.         <em:version>1.0</em:version>
  9.         <em:type>2</em:type>
  10.         <!-- optional items -->
  11.         <em:creator>Your Name Here</em:creator>
  12.         <em:description>A sample extension with advanced features</em:description>
  13.         <em:contributor>A person who helped you</em:contributor>
  14.         <em:contributor>Another one</em:contributor>
  15.         <em:homepageURL>http://sampleextension.mozdev.org/</em:homepageURL>
  16.         <em:updateURL>http://sampleextension.mozdev.org/update.rdf</em:updateURL>
  17.         <em:optionsURL>chrome://sampleext/content/settings.xul</em:optionsURL>
  18.         <em:aboutURL>chrome://sampleext/content/about.xul</em:aboutURL>
  19.         <em:iconURL>chrome://sampleext/skin/mainicon.png</em:iconURL>

  20.          <!-- thinkmail -->
  21.     <em:targetApplication>
  22.       <Description>
  23.         <em:id>{3550f703-e582-4d05-9a08-453d09bdfdc6}</em:id>
  24.         <em:minVersion>1.0</em:minVersion>
  25.         <em:maxVersion>19.*</em:maxVersion>
  26.       </Description>
  27.     </em:targetApplication>
  28. </Description>
  29. </RDF>
  30. 我们先看一下此文件的头部分:
  31. <?xml version="1.0"?>
  32. <RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  33.      xmlns:em="http://www.mozilla.org/2004/em-rdf#">
  34. 负责引入命名空间。而位于头部分下面的 Description 标记,则是此文件的实质性描述。下面对 Description 下的子标功能给予说明。
复制代码
1.2.1   必需的标记
em:id
它用来唯一的标识某个扩展,支持GUID 格式或格式为 extension@domain 的 id。如下示例了两种不同的格式:
<em:id>myextension@mysite.com</em:id><em:id>{daf44bf7-a45e-4450-979c-91cf07434c3d}</em:id>
对于 GUID 格式的 id,我们可以通过一些工具来生成。在 Windows 下,我们可以用微软的 guidgen.exe 工具来生成。如果你在类 Unix 的系统下做开发,你可以用系统自带的 uuidgen 工具来生成。
em:name
此标记的内容会被显示在扩展管理器中。它被允许由多个单词组成,且中间可以包含空格。
em:version
此标记的内容是一个版本字符串,用来表示扩展的当前版本,它会被显示在扩展管理器中。示例如下:
<em:version>2.0</em:version><em:version>1.0.2</em:version><em:version>0.4.1.2005090112</em:version>em:type
此标记正是为区别安装包的类型设计的。它的内容是一个整型值,并且只允许以下几个值出现:
2       Extensions4       Themes8       Locale16      Plugin
对于扩展类型的安装包,type 标记的内容显然要被指定为 2。
em:targetApplication
此标记及其子标记用来指明所适用的 Mozilla 平台。由于你开发的扩展可能适用多个 Mozilla 平台,所以你需要确切地指定它所适用的平台。通过它的 em:id 子标记,可以指明所适用的平台;通过 em:minVersionem:maxVersion 子标记可以进一步所适用平台的版本范围。需要注意的是,如果你编写的扩展在安装时弹出了禁止安装的窗口,多半是由于 em:targetApplication 书写有问题造成的,特别是 em:maxVersion 设置过低的问题。
下面将一些常用的 ThinkMail 平台对应的id 。
ThinkMail              {3550f703-e582-4d05-9a08-453d09bdfdc6}

1.2.2   可选的标记em:creator
此标记的内容用来指明扩展作者的名字。
em:description
此标记的内容用来描述扩展的功能或特性,它会被显示在扩展管理器中。但是,建议你在书写此内容时尽量简明扼要。
em:contributor
此标记的内容用来指明扩展贡献者的名字。如果你在扩展开发过程中,还得到了其他的人帮助,或者用到了其他人的源代码,请在此处写明贡献者的信息。并且,此标记允许存在多个,而 em:creator 标记只允许存在一个。
em:homepageURL
此标记的内容用来指明扩展或作者的主页地址。
em:updateURL
基于 ThinkMail 扩展的最大好处就是可以自动升级,此标记的内容正是用来指明版本检测时的 URL 地址。ThinkMail给扩展提供这样一种升级机制,它通过强制方式或定期检测方式请求升级描述文件,从而获取到有关扩展自身的升级信息,进而对扩展进行升级操作。
具体支持方案?
  1. em:optionsURL
  2. 此标记的内容用来指明当前扩展的选项设置入口,并且要以 chrome:// 地址方式进行指定。由于扩展的一些选项值要由用户来设置,所以扩展的作者有必要为扩展提供一个设置窗口。在扩展管理器中,通过“右键/设置”菜单项,我们 可以对不同的扩展打开不同的设置窗口,这就是此标记完成的功能。但前提是,扩展作者必须要为所开发的扩展编写设置窗口,否则此标记不是必须的。
  3. em:aboutURL
  4. 此标记的内容用来指明自定义“about(关于)”窗口的地址。同 em:optionsURL 标记一样,你必须编写并以 chrome:// 地址方式来提供此信息。
复制代码
em:iconURL
此标记的内容用来指明扩展在扩展管理器中显示的图标,它同样要以 chrome:// 地址方式提供。虽然是图标,但它却经常用 PNG 格式的文件来保存。如果你没有指定自己的图标,ThinkMail 将采用预定义的图案来表示你的扩展。
em:targetPlatform
主要用来限制所运行的操作系统(OS)类型。由于某些扩展有二进制兼容的限制,所以就要限制所安装到的 OS 平台。

1.3   有关 Chrome1.3.1   Chrome 的定义
Chrome 是一组应用程序窗口的用户界面元素集合,它们位于窗口的内容区域之外。工具栏,菜单栏,进度条和窗口标题栏都是这些元素的例子,它们都是典型的 chrome 的一部分。
1.3.2   Chrome 提供者
chrome 提供者是一种为特定的窗口类型提供 chrome 的资源供给机制。从工具栏按钮上的图片到负责描述显示在窗口上的文本,内容和窗口本身的文件都是由 chrome 提供者提供的,这些提供者在一起工作,为特定的窗口提供了一组完整的 chrome。
chrome提供者共有 3 种类型,分别是 ContentLocale Skin。当安装包的 contentlocale skin 目录真正注册到 chrome 系统以后,它们下面的文件就成了 chrome 提供者。这些提供者就可以完成以上提到的那些功能,但前提是,必须通过一种机制来访问这些提供者,这就是 Chrome URL 要完成的功能。
1.3.3   Chrome URL
像已有的其它 URL 协议一样,我们可以通过 chrome:// 这种形式的 URL 协议来访问那些 chrome 提供者(换句话说,就是已经注册在 chrome 系统下的资源)。其实,那些资源是以物理文件或目录方式被存储,通过地址映射机制以 chrome 地址来访问的。但是我们根本不用管其物理地址是什么,ThinkMail 下的扩展及其自身都是以这种映射过的地址来访问的。这样做的最大好处就是屏蔽了文件系统的多样性,为 Mozilla 的跨平台运行打下了基础。同 http 和 ftp 地址格式不一样,Mozilla 对 chrome 地址格式做了严格的规定,如下:
chrome://<package name>/<part>/<file.name>
<package name> 用来指明访问的扩展名称,这个名称在 chrome.manifest 文件被定义。比如,
content demoex chrome/content/
它的 <package name> 是 demoex。
<part> 用来指明访问的 chrome 包类型,它分别允许 content,locale 和 skin 这 3 种固定的类型。
<file.name> 用来指明访问的文件名称,因为前面的 <package name> 和 <part> 已经对文件的路径做了限定,所以,这个文件相对来说是某个明确的文件。
当我们通过这种方式访问 content 类型的文件时,那些文件将被固定的访问;而当我们访问 locale 或 skin 类型的文件时,ThinkMail 会根据自身的语言和皮肤,选择一个最合适的文件来动态访问,这一问题在前面已经提过了。但前提是,你必须提供足够多的语言包和皮肤包供其选择。
如果 <part> 下面还有子目录,你可以像访问文件一样,对子目录下的文件进行相对访问,就像下面这样:
chrome://browser/content/bookmarks/bookmarksManager.xul
另外,chrome 地址还有一种缩略格式,它只被应用在一些特殊的情况下。如下:
chrome://navigator/content/
这看上去是在访问某个目录, 实际上它是
chrome://navigator/content/navigator.xul
的缩写。ThinkMail 会根据你访问的 chrome 资源类型来自动补齐后面的文件名称,规则是
<file.name> =<package name> + (.xul|.dtd|.css)
这种形式的 chrome 地址多用于访问比较规则的包资源。
1.4   扩展安装的实现原理
以上内容已经对扩展的结构做了详细的解释,但有必要解释一下 Firemail 在安装扩展时都做了些什么,这对你了解扩展是如何被注册和工作的都十分有利。在你了解了扩展的安装原理之后,手动注册扩展也不再是什么难以理解的事情了。
1.4.1   注册XPCOM组件到Gecko17
Gecko 17开始,我们需要编辑一个文件“chrome.manifests”,来显示告诉XPCOM系统要注册那个组件。下面是一个例子:
code1.jpg
正如上面的片段所示,第5行(manifest开始的行)表示要在XPCOM系统里注册组件的位置。 详细的细节参见Chromeregistration

code2.jpg
samplecomp.manifest中的内容示例如下:
binary-component   HelloWorld.dll
interfaces   MyComponent.xpt

1.5   chrome.manifest 文件
采用纯文本格式的 chrome.manifest 使 chrome 资源的注册更加方便,并且更利用扩展的开发。
下面先让我们看一个 chrome.manifest 的示例,如下:
content       necko                   jar:comm.jar!/content/necko/ xpcnativewrappers=yeslocale        necko       en-US       jar:en-US.jar!/locale/en-US/necko/content       xbl-marquee             jar:comm.jar!/content/xbl-marquee/content       pipnss                  jar:pipnss.jar!/content/pipnss/locale        pipnss      en-US       jar:en-US.jar!/locale/en-US/pipnss/ overlay chrome://browser/content/pageInfo.xul           chrome://pippki/content/PageInfoOverlay.xul application={ec8030f7-c20a-464f-9b0e-13a3a9e97384}overlay chrome://communicator/content/pref/preftree.xul chrome://pippki/content/PrefOverlay.xuloverlay chrome://navigator/content/pageInfo.xul         chrome://pippki/content/PageInfoOverlay.xul content       pippki                  jar:pippki.jar!/content/pippki/ xpcnativewrappers=yeslocale        pippki      en-US       jar:en-US.jar!/locale/en-US/pippki/content       global-platform         jar:toolkit.jar!/content/global-platform/ platformskin          global      classic/1.0 jar:classic.jar!/skin/classic/global/override chrome://global/content/netError.xhtml jar:embedder.jar!/global/content/netError.xhtmlcontent       inspector               jar:inspector.jar!/content/inspector/ xpcnativewrappers=no
所有的规则是由每个文本行头部的“指令”来标识的,这些指令的解释如下
1.5.1   注册指令content
它用来注册一个 content 类型的包,如下:
content packagename uri/to/files/[flags]
packagename 是所注册的包名称,同 chrome 地址中的 <package name>含义一样。
uri/to/files/ 用来指明这个包资源的操作系统路径,它的格式比较多。对于 %profile% 下的扩展,我们知道在安装之后,ThinkMail 会将顶级结构解压缩生成二级 JAR 文件。对于这种相对路径下的 JAR 文件,我们要采用如:
jar:chrome/cview.jar!/content/cview/
这种格式的 uri 来指明。“jar:”用来指明此 uri 指向的是某个 JAR 文件的内部地址。还有一个特殊的“resource:/”用来代表 ThinkMail应用程序的根目录,例如:
jar:resource:/chrome/pipnss.jar!/content/pipnss/
locale
它用来注册一个 locale 类型的包,格式如下:
locale packagename localenameuri/to/files/ [flags]
localename 用来指明所注册的语言类型,如: en-US,zh-CN 等,其它的同上。
skin
它用来注册一个 skin 类型的包,格式如下:
skin packagename skinnameuri/to/files/ [flags]
skinname 用来指明所注册的皮肤包类型,如: classic/1.0,其它的同上。
overlay
它用来指明 XUL 的“覆盖”规则。
overlaychrome://URI-to-overlay chrome://overlay-URI [flags]

示例:
overlaychrome://messenger/content/messenger.xul chrome://mintrayr/content/messenger/messenger.xul


style
它用来指明 CSS 的“覆盖”规则,这是新加入的特性。通过这个新规则你可以为已有的界面文件引入新的样式表效果。
style chrome://URI-to-stylechrome://stylesheet-URI
示例:
style   chrome://messenger/content/messenger.xulchrome://demoex/skin/masterpasswordplus.css

override
在某些时候,你可能会有完全“重载”或者说是替换某个 chrome 文件的要求,这条指令就可以完成这种要求。
overridechrome://package/type/original-uri.whatever new-resolved-URI
示例:
overridechrome://mintrayr-icon/skin/appicon64.png chrome://branding/content/icon64.png
overridechrome://mintrayr/skin/common.css chrome://mintrayr/skin/common-fx4.cssapplication={ec8030f7-c20a-464f-9b0e-13a3a9e97384} appversion>=4.0b7os=winnt
manifest
可以指定一个次级清单文件。方便区分功能注册或注册不同平台文件。
manifest subdirectory/foo.manifest [flags]

示例:
manifest components/helloworld.manifest

binary-component
Mozilla平台用于注册二进制组件,考虑到兼容性,需要用abi标志。
格式如下:
binary-component components/mycomponent.dll [flags]
示例:
binary-component components/HelloWorld.dll

interfaces
用于加载类型库文件(typelibfile),此文件是由XPIDL文件生成。
格式如下:
interfaces component/mycomponent.xpt [flags]
示例:
interfacescomponents/MyComponent.xpt

component
用于告诉系统,此XPCOM组件是通过脚本JavaScript实现,此CID必须和组件中的ClassID一致。
格式如下:
component {00000000-0000-0000-0000-000000000000} components/mycomponent.js [flags]
示例:
component{ACA545EE-6023-4BF5-B6AB-352BC34EC284} helloworld.js

contract
映射合约ID(一个可读字符串)ClassID,表示一个特定的实现。合约IDcontract ID)一般代表一个组件。
格式如下:
contract @foobar/mycontract;1 {00000000-0000-0000-0000-000000000000} [flags]
示例:
contract@mozilla.richinfo.com/helloworld;1 {ACA545EE-6023-4BF5-B6AB-352BC34EC284}

category
Category这里主要用于生成对应ContractIDs的别名,对别名列表进行管理,以更好的支持对组件的访问等操作,详细参考:categorymanager
格式如下:
category category entry-name value [flags]
示例:
categoryprofile-after-change helloword @mozilla.richinfo.com/helloworld;1
1.5.2   注册指令中的 Flags标识
在上面的注册指令中,你会发现有个 [flags] 标识经常出现行尾 ,这个标识多用来标识特定的 chrome 包属性或限定当前行命令是否可用。下面对那些可以做为 [flags] 标识的内容一一说明。

application
默认是为ThinkMail平台提供的扩展,固ID都固定为如下,或省略不写。
application=app-ID
ThinkMail的ID为{3550f703-e582-4d05-9a08-453d09bdfdc6}。
appversion
它是一个条件类型的标识,用来限定注册包所应用 ThinkMail 平台的版本范围,如下:
appversion=version
appversion<version
appversion<=version
appversion>version
appversion>=version
version 是 ThinkMail 平台的版本,你可以通过 ThinkMail的 关于窗口,查看它的确切版本号。如果某个注册包的范围限定需要多个条件,你同样可以像 application 一样,将多个条件写在同一行。
platform
它是一个关键字标识,用来限定包资源所应用的操作系统类型。由于某些包的使用需要基于特定的操作系统,所以要做这方面的限定。但此标识只能应用在 content 类型的包上,locale 和 skin 类型的包将忽略这个标识。如果对某个 content 包应用了这种标识,你还需要在那个 content 包目录下再建 3 个子目录,将它们分别命名为 win,mac 和 unix,以对应 3 种不同的操作系统 Windows/OS2,OS9/OSX 和 Unix-Like 。在这 3 个目录下,你肯定还要建立一些适用于指定操作系统的文件,如: .dll 或 .sh 文件,所有在这 3 个子目录之外的文件都将被 Mozilla 忽略。如下便是一个应了 platform 的示例:
content global-platformjar:toolkit.jar!/toolkit/content/global-platform/ platform
xpcnativewrappers
它是一个条件类型的标识,对于那些要访问所浏览网页内容的 chrome 代码来说,XPCNativeWrapper 是一种代码保护机制。在有些恶意网页中,网页的编写者可以通过重载网页中的某个 DOM 对象的属性或方法来达到代码注入的效果。当有些 chrome 代码要访问当前网页的某个 DOM 元素时,它肯定要获取此元素的属性或调用其下的某个方法,而如果那个 DOM 元素的属性或方法被使用 JavaScript 重写成了某段恶意代码,chrome 代码的执行肯定脱离了本意,并且变成了恶意代码的执行者,这样恶意网页就达到 chrome 注入攻击的效果。
Mozilla 通过一个叫 XPCNativeWrapper 的机制来取那些真实的属性和方法,来避免 chrome 代码的恶意注入。在以往的程序里,你需要通过手动调用 XPCNativeWrapper 对象来取 DOM 元素的属性,这比较麻烦。在 Firefox 1.5 以后,这个保护特性被默认打开,你不再需要使用 XPCNativeWrapper 对象来读取 DOM 属性了。但是,如果你想关闭这个特性,你必须通过指明 xpcnativewrappers=no 条件来实现,我想很少会有人这么做的。
此条件标识只被应用在 content 类型的包上,locale 和 skin 类型的包将忽略此标识。
abi
Application Binary Interface,应用二进制接口。
如果一个组件只兼容特定的ABI,则可以用此指令来标记,如:
binary-component component/myLib.dll abi=WINNT_x86-MSVC binary-component component/myLib.so abi=Linux_x86-gcc3
See XPCOM ABI for more details.
1.6   chrome.manifest示例content demoex chrome/content/ locale demoex zh-CN chrome/locale/zh-CN/locale demoex en-US chrome/locale/en-US/ skin demoex classic/1.0 chrome/skin/ overlay chrome://messenger/content/messenger.xul chrome://demoex/content/messenger/messenger.xul style   chrome://messenger/content/messenger.xul chrome://demoex/skin/masterpasswordplus.css # iconoverride chrome://mintrayr-icon/skin/appicon64.png chrome://branding/content/icon64.png
1.7   更多详细信息参考

回复

使用道具 举报

0

主题

1

帖子

10

积分

新手上路

Rank: 1

积分
10
发表于 2016-2-5 00:23:38 | 显示全部楼层
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|Archiver|手机版|小黑屋|firemail ( 粤ICP备15085507号-1 )

GMT+8, 2020-6-6 18:28 , Processed in 1.308260 second(s), 22 queries .

Powered by Discuz! X3

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表