XUL的结构

  • 版本网址缩略名: XUL_教程/1-2_XUL的结构
  • 版本标题: XUL的结构
  • 版本 id: 275012
  • 创建于:
  • 创建者: alzhu
  • 是否是当前版本?
  • 评论 29 words added, 83 words removed

修订内容

{{ PreviousNext("XUL Tutorial:Introduction", "XUL Tutorial:The Chrome URL") }}


We'll begin by looking at how the XUL is handled in Mozilla.

现在我们来看看Mozilla浏览器是如何处理XUL的。

How XUL is Handled
XUL是如何处理的

In Mozilla, XUL is handled much in the same way that HTML or other types of content are handled. When you type the URL of an HTML page into the browser's address field, the browser locates the web site and downloads the content. The Mozilla rendering engine takes the content in the form of HTML source and transforms it into a document tree. The tree is then converted into a set of objects that can be displayed on the screen. Style sheets (CSS), images, and other technologies are used to control the presentation. XUL functions in much the same way.

Mozilla浏览器内部使用跟HTML的处理非常相似的方法来处理XUL:当你在浏览器的地址栏里面输入HTML页面的URL以后,浏览器就定位这个网址并下载页面内容,然后Mozilla将页面内容转换成树的数据结构,最后再将树转换成对象集合,集合中的对象最终被展现在屏幕上就成了我们所见的网页。CSS, 图片以及其他技术被用来控制页面的展现。XUL的处理过程与此非常类似。

In fact, in Mozilla, all document types, whether they are HTML or XUL, or even SVG, are all handled by the same underlying code. This means that the same CSS properties may be used to style both HTML and XUL, and many of the features can be shared between both. However, there are some features that are specific to HTML such as forms, and others which are specific to XUL such as overlays. Since XUL and HTML are handled in the same way, you can load both from either your local file system, from a web page, or from an extension or standalone XULRunner application.

实际上,HTML和XUL以及SVG,所有的文档类型在Mozilla浏览器内部都是使用同一段代码来处理的。这意味着相同的CSS属性对HTML和XUL可能会产生相同的作用,并且很多CSS特性也可以在HTML和XUL之间共享。不过,还是有一些CSS特性是只针对HTML的,比如表格forms;而另外一些CSS特性只针对XUL,比如overlays。因为XUL和HTML都是使用相同的方法来处理的,因此二者都可以从本地文件系统、从远程网站或者是本地的扩展和XULRunner应用程序中装载。

Content from remote sources eg http://localhost/~username/, regardless of whether they are HTML or XUL or another document type, are limited in the type of operations they can perform, for security reasons. For this reason, Mozilla provides a method of installing content locally and registering the installed files as part of its chrome system. This allows a special URL form to be used called a chrome:// URL. By accessing a file using a chrome URL, the files receive elevated privileges to access local files, access preferences and bookmarks and perform other privileged operations. Obviously, web pages do not get these privileges, unless they are signed with a digital certificate and the user has granted permission to perform these operations.

出于安全性的考虑,从远程网站读取的HTML、XUL和其他类型的文档,都只能执行有限的操作。Mozilla浏览器提供了一种在本地安装和注册到chrome系统的方法,通过这种方式,Mozilla浏览器允许一种称为chrome://URL的特殊URL格式来访问文件,以便获得存取本地文件、选项和书签此类操作的权限,而通过远程获取的页面则不具备这种权限,除非这些远程页面签署了数字证书并且浏览器使用者允许远程页面具备执行这些操作的权限。

This chrome package registration is the way Firefox extensions are able to add features to the browser. The extensions are small packages of XUL files, JavaScript, style sheets and images packed together into a single file. This file can be created by using a ZIP utility. When the user downloads it, it will be installed onto the user's machine. It will hook into the browser using a XUL specific feature called an overlay which allows the XUL from the extension and the XUL in the browser to combine together. To the user, it may seem like the extension has modified the browser, but in reality, the code is all separate, and the extension may be uninstalled easily. Registered packages are not required to use overlays, of course. If they don't, you won't be able to access them via the main browser interface, but you can still access them via the chrome URL, if you know what it is.

Firefox浏览器扩展通过注册为chrome包的方式来为浏览器增加更多的特性。这些扩展是由很小的XUL文件、JavaScript文件以及CSS文件、图片打包而成的单个文件。这个打包文件可以使用任意支持ZIP格式得压缩工具来创建。用户下载了这些打包文件并且安装好之后,浏览器就可以使用一种称为overlay的XUL特性来将扩展中的XUL和浏览器的XUL结合在一起。从用户的角度来看,这些XUL结合在一起的效果就像是扩展修改了浏览器的外观和行为,但是实际上,扩展的代码和浏览器的代码是隔离的,并且扩展可以很轻松的被卸载掉。需要指出的是,已安装的扩展并不一定会使用overlay的特性。如果扩展包没有使用overlay的特性,浏览器就不能通过通常的方式来使用这些扩展,而只能通过chrome://URL的方式来访问它们。

Standalone XUL applications may include XUL code in a similar way, but, of course, the XUL for the application will be included as part of the installation, instead of having to be installed separately as an extension. However, this XUL code will be registered in the chrome system such that the application can display the UI.

XUL应用程序的XUL代码通常是作为应用程序安装包的一部分,而不是像浏览器扩展那样独立于浏览器的,当然XUL应用程序的XUL代码也可以独立于XUL应用程序,当XUL代码独立于XUL应用程序的时候,就需要把这些独立的XUL代码注册到chrome系统中以便XUL应用程序能够展示这些代码所具有应用程序界面元素。

It is worth noting that the Mozilla browser itself is actually just a set of packages containing XUL files, JavaScript and style sheets. These files are accessed via a chrome URL and have enhanced privileges and work just like any other package. Of course, the browser is much larger and more sophisticated than most extensions. Firefox and Thunderbird as well as number of other components are all written in XUL and are all accessible via chrome URLs. You can examine these packages by looking in the chrome directory where Firefox or another XUL application is installed.

Mozilla浏览器本身就是由一系列的包含XUL文件、JavaScript文件和CSS文件的压缩文件构成的。这些压缩文件通过chrome://URL的方式被访问,其工作原理跟浏览器扩展是一样的,并且具有比扩展更多的访问权限,区别只在于浏览器要比扩展更加庞大和复杂。Firefoxe、Thunderbird和其他为数众多的组件都是由XUL文件构成的,并且都是通过chrome的方式来访问。你可以在Firefox或者其他XUL应用程序的安装目录下的chrome目录中查看这些压缩包的内容来确认这一点。

The chrome URL always begins with 'chrome://'. Much like how the 'http://' URL always refers to remote web sites accessed using HTTP and the 'file://' URL always refers to local files, the 'chrome://' URL always refers to installed packages and extensions. We'll look more at the syntax of a chrome URL in the next section. It is important to note that when accessing content through a chrome URL, it gains the enhanced privileges described above that other kinds of URLs do not. For instance, an HTTP URL does not have any special privileges, and an error will occur if a web page tries, for example, to read a local file. However, a file loaded via a chrome URL will be able to read files without restriction.

HTTP通过"http://"来访问远程站点,"file://"则被用来访问本地文件,chrome采用与此类似的方式来访问安装包和扩展,如"chrome://"。我们将会在下一节中找到更多的chrome的语法。通过chrome来访问URL会获得比其他方式如"http://"和"file://"更多的访问权限,意识到这一点很重要。举例来说,当一个通过http://URL加载的页面读取本地文件时由于HTTP页面不具备访问本地文件的权限,因此将会出现一个错误;但是一个通过chrome://URL加载的页面就能够没有任何限制的读取本地文件。

This distinction is important. This means that there are certain things that content of web pages cannot do, such as read the user's bookmarks. This distinction is not based on the kind of content being displayed; only on the type of URL used. Both HTML and XUL placed on a web site have no extra permissions; however both HTML and XUL loaded through a chrome URL have enhanced permissions.

这种区别非常重要,这意味着http方法访问的网页的能力存在一定的局限性,比如网页不能读取用户的书签,而chrome方式访问的页面则可以读取用户的书签。这种区别只基于页面访问的方式是HTTP还是chrome,而不是基于页面的内容。通过HTTP访问同样放置于远程站点上的HTML文件和XUL文件,二者之间在访问权限上并没有什么差别;而当使用chrome来访问远程的HTML文件和XUL文件,二者将会具有更多的访问权限。

If you are going to use XUL on a web site, you can just put the XUL file on the web site as you would an HTML file, and then load its URL in a browser http://localhost/xul.php. Ensure that your web server is configured to send XUL files with the content type of application/vnd.mozilla.xul+xml (eg with PHP header('Content-type: application/vnd.mozilla.xul+xml');). This content type is how Mozilla knows the difference between HTML and XUL. Mozilla does not use the file extension, unless reading files from the file system, but you should use the .xul extension for all XUL files. You can load XUL files from your own machine by opening them in the browser, or by double-clicking the file in your file manager.

如果你打算在你的web站点上使用XUL文件,你需要做的一切跟HTML没有什么两样,然后在浏览器地址栏中输入http://localhost/xul.php来访问它。为了能够通过浏览器访问XUL文件,你的web服务器要能够在送出XUL文件内容之前加上"application/vnd.mozilla.xul+xml"的头部(比如使用PHP来发送: header('Content-type: application/vnd.mozilla.xul+xml'))。Mozilla浏览器依靠header的内容来识别接收到的远程文件是HTML还是XUL, 而不是依靠文件的扩展名;对于本地文件,则是依靠扩展名来识别的。不管是远程文件还是本地文件,我们最好使用.xul扩展名来命名XUL文件。你可以通过浏览器来访问本机的XUL文件或者在本地XUL文件上双击它。

Remember that remote XUL will have significant restrictions on what it can do.
请牢记远程XUL文件的访问权限有很大的限制。

Document types: HTML XML XUL CSS

    Mozilla 对 HTML 及 XUL 使用完全不同的文件对象 (DOM) ,尽管二者共享着多数功能。在 Mozilla 里的三种主要文件格式:HTML,、XML 及 XUL。HTML 和 XUL 分别对应于 HTML 和 XUL 文档,XML 用于其他类型的 XML 文件。 由于 XUL 也是 XML, XUL 是一般的 XML 的子类型,这就使得在功能上有一些微妙的差异。比如说,对于 HTML 通过 document.forms 属性处理表格是允许的,但对于XUL则不行。这是因为 XUL 不包含 forms 元素。另外 XUL 的特殊功能如覆盖(overlays)和模板(templates)仅对XUL文件有效。

    这种文档之间的区分是很重要的。有些 XUL 功能是在不同文件类型中没有差异,可以在 HTML 或 XML 文档中使用 。而其他的则需要特定的文件类型。比如说你可以使用在其他文档中使用 XUL 布局方式。

总结以上:

  • Mozilla 使用同样的底层模块处理 HTMLXUL 并使用 CSS 描述其呈现效果。
  • XUL 可由远程站点,本地文件系统加载。或者当作一个包被安装,使用 chrome URL访问。最后一个选择正是浏览器扩展所使用的。
  • Chrome URL 用于访问已安装的包并以更高的权限使用他们。
  • HTML、XML、及 XUL 使用不同的文件对象。一些功能在这些文件格式中均有效,而有些则针对特定的文件类型。

下面的几章将讨论一个可以安装到 Mozilla 的 chrome 包的基本结构。然而,如果你仅仅希望创建一个简单的程序,你可以跳到 Creating a Window 一章。

Package Organization

Mozilla is organized in such a way that you can have as many components as you want pre-installed. Each extension is also a component with a separate chrome URL. It also has one component for each installed theme and locale. Each of these components, or packages, is made up of a set of files that describe the user interface for it. For example, the messenger component has descriptions of the mail messages list window, the composition window and the address book dialogs.

The packages that are provided with Mozilla are located within the chrome directory, which are in the directory where you installed Mozilla. The chrome directory is where you find all the files that describe the user interface used by the Mozilla browser, mail client, and other applications. Typically, you put all the XUL files for an application in this directory, although extensions are installed in the extensions directory for a particular user. Just copying a XUL file into the chrome directory doesn't give the file any extra permissions, nor can it be accessed via a chrome URL. To gain the extra privileges, you will need to create a manifest file and put that in the chrome directory. This file is easy to create, as it is typically only a couple of lines long. It is used to map a chrome URL to a file or directory path on the disk where the XUL files are located. Details of how to create this file will be discussed in a later section.

The only way to create content that can be accessed through a chrome URL is by creating a package as described in the next few sections. This directory is called 'chrome' likely because it seemed like a convenient name to use for the directory where the chrome packages that are included with Mozilla are kept.

To further the confusion, there are two other places where the word "chrome" might appear. These are the -chrome command line argument and the chrome modifier to the window.open() function. Neither of these features grant extra privileges; instead they are used to open a new top-level window without the browser UI such as the menu and toolbar. You will commonly use this feature in more complex XUL applications since you wouldn't want the browser UI to exist around your dialog boxes.

The files for a package are usually combined into a single JAR file. A JAR file may created and examined using a ZIP utility. For instance, you can open the JAR files in Mozilla's chrome directory to see the basic structure of a package. Although it's normal to combine the files into a JAR file, packages may also be accessed in expanded form into a directory. Although you don't normally distribute a package this way, it is handy during development since you can edit the file directly and then reload the XUL file without having to repackage or reinstall the files.

By default, Mozilla applications parse XUL files and scripts, and store a pre-compiled version in memory for the remainder of the application session. This improves performance. However, because of this, the XUL will be not be reloaded even when the source files are changed. To disable this mechanism, it is necessary to change the preference nglayout.debug.disable_xul_cache. In Firefox, this preference may be added to the user preferences by typing "about:config" in the address field, and setting this value to true. Or, just manually edit your user.js preferences file and add the following line:

pref("nglayout.debug.disable_xul_cache", true);

There are usually three different parts to a chrome package, although they are all optional. Each part is stored in a different directory. These three sets are the content, the skin, and the locale, which are all described below. A particular package might provide one or more skins and locales, but a user can replace them with their own. In addition, the package might include several different applications, each accessible via different chrome URLs. The packaging system is flexible enough so that you can include whatever parts you need and allow other parts, such as the text for different languages, to be downloaded separately.

The three types of chrome packages are:

  • Content - Windows and scripts
    The declarations of the windows and the user interface elements contained within them. These are stored in XUL files, which have a .xul extension. A content package can have multiple XUL files, but the main window should have a filename that is the same as the package name. For example, the editor package will have a file within it called editor.xul. Scripts are placed in separate files alongside the XUL files.
  • Skin - Style sheets, images and other theme specific files
    Style sheets describe details of the appearance of a window. They are stored separately from XUL files to facilitate modifying the skin (theme) of an application. Any images used are stored here also.
  • Locale - Locale specific files
    All the text that is displayed within a window is stored separately. This way, a user can have a set for their own language.

Content Packages

The name of the JAR file might describe what it contains, but you can't be sure unless you view its contents. Let's use the browser package included with Firefox as an example. If you extract the files in browser.jar, you will find that it contains a directory structure much like the following:

content
   browser
      browser.xul
      browser.js
      -- other browser XUL and JS files goes here --
      bookmarks
         -- bookmarks files go here --
      preferences
         -- preferences files go here --
.
.
.

This is easily recognizable as a content package, as the top-level directory is called content. For skins, this directory will usually be called skin and for locales, it will usually be called locale. This naming scheme isn't necessary, but this is a common convention to make the parts of a package clearer. Some packages may include a content section, a skin, and a locale. In this case, you will find a subdirectory for each type. For example, Chatzilla is distributed in this way.

The content/browser directory contains a number of files with .xul and .js extensions. The XUL files are the ones with the .xul extension. The files with .js extensions are JavaScript files containing scripts that handle the functionality of a window. Many XUL files have a script file associated with them, and some may have more than one.

In the listing above, two files have been shown. There are of course others, but for simplicity they aren't shown. The file browser.xul is the XUL file that describes the main browser window. The main window for a content package should have the same name as the package with a .xul extension. In this case, the package name is "browser" so we expect to find browser.xul. Some of the other XUL files describe separate windows. For example, the file pageInfo.xul describes the page info dialog.

Many packages will include a contents.rdf file, which describes the package, its author, and the overlays it uses. However, this file is obsolete and has been replaced with a simpler mechanism. This newer method is the manifest file mentioned earlier, and you will find these as files with the .manifest extension in the chrome directory. For instance, browser.manifest describes the browser package.

Several subdirectories, such as bookmarks and preferences, describe additional sections of the browser component. They are placed in different directories only to keep the files more organized.

Skins or Themes

Although the underlying code for Mozilla calls them skins and the user interface calls them themes, they're both referring to the same thing. The classic.jar file describes the default theme provided with Firefox. The structure is similar to the content packages. For example, examining classic.jar:

skin
   classic
      browser
         browser.css
         -- other browser skin files go here --
      global
         -- global skin files go here --
.
.
.

Again, this directory structure isn't necessary and is used for convenience. You can actually put all the files in one directory at the top level and not use subdirectories. However, for larger applications, subdirectories are used to separate the different components. In the example above, a directory exists for theme related files for the browser and another for global theme related files. The global directory contains skin files that are general to all packages. These files will apply to all components and will be included with your own standalone applications. The global part defines the appearance of all of the common XUL widgets, whereas the other directories have files that are specific to those applications. Firefox includes both the global and browser theme files in one archive, but they can be included separately.

A skin is made up of CSS files and a number of images used to define the look of an interface. The file browser.css is used by browser.xul and contains styles that define the appearance of various parts of the browser interface. Again, note how the file browser.css has the same name as the package. By changing the CSS files, you can adjust the appearance of a window without changing its function. This is how you can create a new theme. The XUL part remains the same but the skin part changes independently.

Locales

The file en-US.jar describes the language information for each component, in this case for US English. Like the skins, each language file contains files that specify text used by the package for a specific language. The locale structure is similar to the others, so it won't be listed here.

The localized text is stored in two types of files: DTD files and properties files. The DTD files have a .dtd extension and contain entity declarations, one for each text string that is used in a window. For example, the file browser.dtd contains entity declarations for each menu command. In addition, keyboard shortcuts for each command are also defined, because they may be different for each language. DTD files are used by XUL files so, in general, you will have one per XUL file. The locale part also contains properties files, which are similar, but are used by script files. The file browser.properties contains a few such localized strings.

This structure allows you to translate Mozilla or a component into a different language by just adding a new locale for that language. You don't have to change the XUL code at all. In addition, another person could supply a separate package that applies a skin or locale to your content part, thus providing support for a new theme or language without having to change the original package.

其他的包

    有一个特殊的包叫做 toolkit (或 global)。早在涉及 skins 我们就看了 global 文件。toolkit.jar 文件包含它对应的内容。这里有一些通用的对话框及定义。这里也包含了丰富的 XUL 组件(如 textboxes 及 buttons)的定义及功能。在 global\skin 目录下的文件定义了全部 XUL界面元素的默认外观。toolkit 包被所有 XUL程序使用。

Adding a Package

Mozilla places the packages that are included with the installation in the chrome directory. However, they do not need to be placed there. When installing another package, you can place it anywhere on the disk, as long as a manifest file points to it. It is common to place packages into the chrome directory simply because it is convenient; however, they will work just as well from another directory or somewhere on your local network. You cannot store them on a remote site, unless the remote site is mounted through the local file system.

There are two chrome directories used for XUL applications: one is installed in the same place where the application is installed, while the other is part of user's profile. The former allows packages that are shared by all users while the latter allows packages to be created only for a specific user or users. Extensions, while installed in a separate extensions directory, are also usually user specific. Any manifest files located in either chrome directory will be examined to see which packages are installed.

In the next section, we'll look at how to refer to chrome packages using the chrome URL.

{{ PreviousNext("XUL Tutorial:Introduction", "XUL Tutorial:The Chrome URL") }} Interwiki Language Links

{{ languages( { "es": "es/Tutorial_de_XUL/Estructura_XUL", "fr": "fr/Tutoriel_XUL/La_structure_XUL", "ja": "ja/XUL_Tutorial/XUL_Structure", "pl": "pl/Kurs_XUL/Struktura_XUL", "de": "de/XUL_Tutorial/XUL_Struktur" } ) }}

修订版来源

<p>{{ PreviousNext("XUL Tutorial:Introduction", "XUL Tutorial:The Chrome URL") }}</p>
<p><br>
We'll begin by looking at how the XUL is handled in Mozilla. <br>
<br>
现在我们来看看Mozilla浏览器是如何处理XUL的。</p>
<h3 name="How_XUL_is_Handled">How XUL is Handled<br>
XUL是如何处理的</h3>
<p>In Mozilla, XUL is handled much in the same way that HTML or other types of content are handled. When you type the URL of an HTML page into the browser's address field, the browser locates the web site and downloads the content. The Mozilla rendering engine takes the content in the form of HTML source and transforms it into a document tree. The tree is then converted into a set of objects that can be displayed on the screen. Style sheets (<a href="/cn/CSS" title="cn/CSS">CSS</a>), images, and other technologies are used to control the presentation. XUL functions in much the same way.<br>
<br>
Mozilla浏览器内部使用跟HTML的处理非常相似的方法来处理XUL:当你在浏览器的地址栏里面输入HTML页面的URL以后,浏览器就定位这个网址并下载页面内容,然后Mozilla将页面内容转换成树的数据结构,最后再将树转换成对象集合,集合中的对象最终被展现在屏幕上就成了我们所见的网页。CSS, 图片以及其他技术被用来控制页面的展现。XUL的处理过程与此非常类似。</p>
<p>In fact, in Mozilla, all document types, whether they are HTML or XUL, or even <a href="/cn/SVG" title="cn/SVG">SVG</a>, are all handled by the same underlying code. This means that the same CSS properties may be used to style both HTML and XUL, and many of the features can be shared between both. However, there are some features that are specific to HTML such as forms, and others which are specific to XUL such as <a href="/cn/XUL_Tutorial/Overlays" title="cn/XUL_Tutorial/Overlays">overlays</a>. Since XUL and HTML are handled in the same way, you can load both from either your local file system, from a web page, or from an extension or standalone <a href="/cn/XULRunner" title="cn/XULRunner">XULRunner</a> application.</p>
<p>实际上,HTML和XUL以及SVG,所有的文档类型在Mozilla浏览器内部都是使用同一段代码来处理的。这意味着相同的CSS属性对HTML和XUL可能会产生相同的作用,并且很多CSS特性也可以在HTML和XUL之间共享。不过,还是有一些CSS特性是只针对HTML的,比如表格forms;而另外一些CSS特性只针对XUL,比如overlays。因为XUL和HTML都是使用相同的方法来处理的,因此二者都可以从本地文件系统、从远程网站或者是本地的扩展和XULRunner应用程序中装载。</p>
<p>Content from remote sources <code><span class="nowiki">eg http://localhost/~username/</span></code>, regardless of whether they are HTML or XUL or another document type, are limited in the type of operations they can perform, for security reasons. For this reason, Mozilla provides a method of installing content locally and registering the installed files as part of its <strong><a href="/cn/Chrome" title="cn/Chrome">chrome</a></strong> system. This allows a special URL form to be used called a <code><a class=" external" href="chrome://" rel="freelink">chrome://</a></code> URL. By accessing a file using a chrome URL, the files receive elevated privileges to access local files, access preferences and bookmarks and perform other privileged operations. Obviously, web pages do not get these privileges, unless they are signed with a digital certificate and the user has granted permission to perform these operations.</p>
<p>出于安全性的考虑,从远程网站读取的HTML、XUL和其他类型的文档,都只能执行有限的操作。Mozilla浏览器提供了一种在本地安装和注册到chrome系统的方法,通过这种方式,<a class=" external" href="Mozilla浏览器允许一种称为chrome://URL的特殊URL格式来访问文件" rel="freelink">Mozilla浏览器允许一种称为chrome://URL的特殊URL格式来访问文件</a>,以便获得存取本地文件、选项和书签此类操作的权限,而通过远程获取的页面则不具备这种权限,除非这些远程页面签署了数字证书并且浏览器使用者允许远程页面具备执行这些操作的权限。</p>
<p>This <strong>chrome</strong> package registration is the way Firefox extensions are able to add features to the browser. The extensions are small packages of XUL files, JavaScript, style sheets and images packed together into a single file. This file can be created by using a ZIP utility. When the user downloads it, it will be installed onto the user's machine. It will hook into the browser using a XUL specific feature called an <a href="/cn/Overlay" title="cn/Overlay">overlay</a> which allows the XUL from the extension and the XUL in the browser to combine together. To the user, it may seem like the extension has <em>modified</em> the browser, but in reality, the code is all separate, and the extension may be uninstalled easily. Registered packages are not required to use overlays, of course. If they don't, you won't be able to access them via the main browser interface, but you can still access them via the chrome URL, if you know what it is.</p>
<p>Firefox浏览器扩展通过注册为chrome包的方式来为浏览器增加更多的特性。这些扩展是由很小的XUL文件、JavaScript文件以及CSS文件、图片打包而成的单个文件。这个打包文件可以使用任意支持ZIP格式得压缩工具来创建。用户下载了这些打包文件并且安装好之后,浏览器就可以使用一种称为overlay的XUL特性来将扩展中的XUL和浏览器的XUL结合在一起。从用户的角度来看,这些XUL结合在一起的效果就像是扩展修改了浏览器的外观和行为,但是实际上,扩展的代码和浏览器的代码是隔离的,并且扩展可以很轻松的被卸载掉。需要指出的是,已安装的扩展并不一定会使用overlay的特性。如果扩展包没有使用overlay的特性,浏览器就不能通过通常的方式来使用这些扩展,而只能通过chrome://URL的方式来访问它们。</p>
<p>Standalone XUL applications may include XUL code in a similar way, but, of course, the XUL for the application will be included as part of the installation, instead of having to be installed separately as an extension. However, this XUL code will be registered in the chrome system such that the application can display the UI.</p>
<p>XUL应用程序的XUL代码通常是作为应用程序安装包的一部分,而不是像浏览器扩展那样独立于浏览器的,当然XUL应用程序的XUL代码也可以独立于XUL应用程序,当XUL代码独立于XUL应用程序的时候,就需要把这些独立的XUL代码注册到chrome系统中以便XUL应用程序能够展示这些代码所具有应用程序界面元素。</p>
<p>It is worth noting that the Mozilla browser itself is actually just a set of packages containing XUL files, JavaScript and style sheets. These files are accessed via a chrome URL and have enhanced privileges and work just like any other package. Of course, the browser is much larger and more sophisticated than most extensions. Firefox and Thunderbird as well as number of other components are all written in XUL and are all accessible via chrome URLs. You can examine these packages by looking in the chrome directory where Firefox or another XUL application is installed.</p>
<p>Mozilla浏览器本身就是由一系列的包含XUL文件、JavaScript文件和CSS文件的压缩文件构成的。这些压缩文件通过chrome://URL的方式被访问,其工作原理跟浏览器扩展是一样的,并且具有比扩展更多的访问权限,区别只在于浏览器要比扩展更加庞大和复杂。Firefoxe、Thunderbird和其他为数众多的组件都是由XUL文件构成的,并且都是通过chrome的方式来访问。你可以在Firefox或者其他XUL应用程序的安装目录下的chrome目录中查看这些压缩包的内容来确认这一点。</p>
<p>The chrome URL always begins with '<a class=" external" href="chrome://" rel="freelink">chrome://</a>'. Much like how the <span class="nowiki">'http://'</span> URL always refers to remote web sites accessed using HTTP and the '<a class=" external" href="file://" rel="freelink">file://</a>' URL always refers to local files, the '<a class=" external" href="chrome://" rel="freelink">chrome://</a>' URL always refers to installed packages and extensions. We'll look more at the syntax of a chrome URL in the next section. It is important to note that when accessing content through a chrome URL, it gains the enhanced privileges described above that other kinds of URLs do not. For instance, an HTTP URL does not have any special privileges, and an error will occur if a web page tries, for example, to read a local file. However, a file loaded via a chrome URL will be able to read files without restriction.</p>
<p>HTTP通过"<a class=" external" href="http://" rel="freelink">http://</a>"来访问远程站点,"<a class=" external" href="file://" rel="freelink">file://</a>"则被用来访问本地文件,chrome采用与此类似的方式来访问安装包和扩展,如"<a class=" external" href="chrome://" rel="freelink">chrome://</a>"。我们将会在下一节中找到更多的chrome的语法。通过chrome来访问URL会获得比其他方式如"<a class=" external" href="http://" rel="freelink">http://</a>"和"<a class=" external" href="file://" rel="freelink">file://</a>"更多的访问权限,意识到这一点很重要。举例来说,当一个通过http://URL加载的页面读取本地文件时由于HTTP页面不具备访问本地文件的权限,因此将会出现一个错误;但是一个通过chrome://URL加载的页面就能够没有任何限制的读取本地文件。</p>
<p>This distinction is important. This means that there are certain things that content of web pages cannot do, such as read the user's bookmarks. This distinction is not based on the kind of content being displayed; only on the type of URL used. Both HTML and XUL placed on a web site have no extra permissions; however both HTML and XUL loaded through a chrome URL have enhanced permissions.</p>
<p>这种区别非常重要,这意味着http方法访问的网页的能力存在一定的局限性,比如网页不能读取用户的书签,而chrome方式访问的页面则可以读取用户的书签。这种区别只基于页面访问的方式是HTTP还是chrome,而不是基于页面的内容。通过HTTP访问同样放置于远程站点上的HTML文件和XUL文件,二者之间在访问权限上并没有什么差别;而当使用chrome来访问远程的HTML文件和XUL文件,二者将会具有更多的访问权限。</p>
<p>If you are going to use XUL on a web site, you can just put the XUL file on the web site as you would an HTML file, and then load its URL in a browser <small><span class="nowiki">http://localhost/xul.php</span></small>. Ensure that your web server is configured to send XUL files with the content type of <strong><code>application/vnd.mozilla.xul+xml</code></strong> (eg with PHP <code>header('Content-type: application/vnd.mozilla.xul+xml');</code>). This content type is how Mozilla knows the difference between HTML and XUL. Mozilla does not use the file extension, unless reading files from the file system, but you should use the <code>.xul</code> extension for all XUL files. You can load XUL files from your own machine by opening them in the browser, or by double-clicking the file in your file manager.</p>
<p>如果你打算在你的web站点上使用XUL文件,你需要做的一切跟HTML没有什么两样,然后在浏览器地址栏中输入http://localhost/xul.php来访问它。为了能够通过浏览器访问XUL文件,你的web服务器要能够在送出XUL文件内容之前加上"application/vnd.mozilla.xul+xml"的头部(比如使用PHP来发送: header('Content-type: application/vnd.mozilla.xul+xml'))。Mozilla浏览器依靠header的内容来识别接收到的远程文件是HTML还是XUL, 而不是依靠文件的扩展名;对于本地文件,则是依靠扩展名来识别的。不管是远程文件还是本地文件,我们最好使用.xul扩展名来命名XUL文件。你可以通过浏览器来访问本机的XUL文件或者在本地XUL文件上双击它。</p>
<div class="tip">Remember that remote XUL will have significant restrictions on what it can do.</div>
<div class="tip">请牢记远程XUL文件的访问权限有很大的限制。</div>
<h4 name="Document_types:_HTML_XML_XUL_CSS">Document types: HTML XML XUL CSS</h4>
<p>    Mozilla 对 HTML 及 XUL 使用完全不同的文件对象 (<a href="/cn/DOM" title="cn/DOM">DOM</a>) ,尽管二者共享着多数功能。在 Mozilla 里的三种主要文件格式:HTML,、XML 及 XUL。HTML 和 XUL 分别对应于 HTML 和 XUL 文档,XML 用于其他类型的 XML 文件。 由于 XUL 也是 XML, XUL 是一般的 XML 的子类型,这就使得在功能上有一些微妙的差异。比如说,对于 HTML <code>通过 document.forms 属性处理</code>表格是允许的,但对于XUL则不行。这是因为 XUL 不包含 forms 元素。另外 XUL 的特殊功能如覆盖(overlays)和模板(templates)仅对XUL文件有效。</p>
<p>    这种文档之间的区分是很重要的。有些 XUL 功能是在不同文件类型中没有差异,可以在 HTML 或 XML 文档中使用 。而其他的则需要特定的文件类型。比如说你可以使用在其他文档中使用 XUL 布局方式。</p>
<p>总结以上:</p>
<ul> <li>Mozilla 使用同样的底层模块处理 <a href="/cn/HTML" title="cn/HTML">HTML</a> 及 <a href="/cn/XUL" title="cn/XUL">XUL</a> 并使用 <a href="/cn/CSS" title="cn/CSS">CSS</a> 描述其呈现效果。</li> <li>XUL 可由远程站点,本地文件系统加载。或者当作一个包被安装,使用 <a href="/cn/Chrome" title="cn/Chrome">chrome</a> URL访问。最后一个选择正是浏览器扩展所使用的。</li> <li>Chrome URL 用于访问已安装的包并以更高的权限使用他们。</li> <li>HTML、XML、及 XUL 使用不同的文件对象。一些功能在这些文件格式中均有效,而有些则针对特定的文件类型。</li>
</ul>
<p>下面的几章将讨论一个可以安装到 Mozilla 的 chrome 包的基本结构。然而,如果你仅仅希望创建一个简单的程序,你可以跳到 <a href="/cn/XUL_Tutorial/Creating_a_Window" title="cn/XUL_Tutorial/Creating_a_Window">Creating a Window</a> 一章。</p><h3 name="Package_Organization">Package Organization</h3>
<p>Mozilla is organized in such a way that you can have as many components as you want pre-installed. Each extension is also a component with a separate chrome URL. It also has one component for each installed theme and locale. Each of these components, or packages, is made up of a set of files that describe the user interface for it. For example, the messenger component has descriptions of the mail messages list window, the composition window and the address book dialogs.</p>
<p>The packages that are provided with Mozilla are located within the chrome directory, which are in the directory where you installed Mozilla. The chrome directory is where you find all the files that describe the user interface used by the Mozilla browser, mail client, and other applications. Typically, you put all the XUL files for an application in this directory, although extensions are installed in the extensions directory for a particular user. Just copying a XUL file into the <code>chrome</code> directory doesn't give the file any extra permissions, nor can it be accessed via a chrome URL. To gain the extra privileges, you will need to create a manifest file and put that in the chrome directory. This file is easy to create, as it is typically only a couple of lines long. It is used to map a chrome URL to a file or directory path on the disk where the XUL files are located. Details of how to create this file will be discussed in a <a href="/cn/XUL_Tutorial/Manifest_Files" title="cn/XUL_Tutorial/Manifest_Files">later section</a>.</p>
<p>The only way to create content that can be accessed through a chrome URL is by creating a package as described in the next few sections. This directory is called 'chrome' likely because it seemed like a convenient name to use for the directory where the chrome packages that are included with Mozilla are kept.</p>
<p>To further the confusion, there are two other places where the word "chrome" might appear. These are the <code>-chrome</code> command line argument and the <code>chrome</code> modifier to the <code><a href="/cn/DOM/window.open" title="cn/DOM/window.open">window.open()</a></code> function. Neither of these features grant extra privileges; instead they are used to open a new top-level window without the browser UI such as the menu and toolbar. You will commonly use this feature in more complex XUL applications since you wouldn't want the browser UI to exist around your dialog boxes.</p>
<p>The files for a package are usually combined into a single JAR file. A JAR file may created and examined using a ZIP utility. For instance, you can open the JAR files in Mozilla's <code>chrome</code> directory to see the basic structure of a package. Although it's normal to combine the files into a JAR file, packages may also be accessed in expanded form into a directory. Although you don't normally distribute a package this way, it is handy during development since you can edit the file directly and then reload the XUL file without having to repackage or reinstall the files.</p>
<p>By default, Mozilla applications parse XUL files and scripts, and store a pre-compiled version in memory for the remainder of the application session. This improves performance. However, because of this, the XUL will be not be reloaded even when the source files are changed. To disable this mechanism, it is necessary to change the preference <code>nglayout.debug.disable_xul_cache</code>. In Firefox, this preference may be added to the user preferences by typing "about:config" in the address field, and setting this value to true. Or, just manually edit your <code>user.js</code> preferences file and add the following line:</p>
<pre class="eval">pref("nglayout.debug.disable_xul_cache", true);
</pre>
<p>There are usually three different parts to a chrome package, although they are all optional. Each part is stored in a different directory. These three sets are the content, the skin, and the locale, which are all described below. A particular package might provide one or more skins and locales, but a user can replace them with their own. In addition, the package might include several different applications, each accessible via different chrome URLs. The packaging system is flexible enough so that you can include whatever parts you need and allow other parts, such as the text for different languages, to be downloaded separately.</p>
<p>The three types of chrome packages are:</p>
<ul> <li><strong>Content</strong> - Windows and scripts<br> The declarations of the windows and the user interface elements contained within them. These are stored in XUL files, which have a <code>.xul</code> extension. A content package can have multiple XUL files, but the main window should have a filename that is the same as the package name. For example, the editor package will have a file within it called <code>editor.xul</code>. Scripts are placed in separate files alongside the XUL files.</li> <li><strong>Skin</strong> - Style sheets, images and other theme specific files<br> Style sheets describe details of the appearance of a window. They are stored separately from XUL files to facilitate modifying the skin (theme) of an application. Any images used are stored here also.</li> <li><strong>Locale</strong> - Locale specific files<br> All the text that is displayed within a window is stored separately. This way, a user can have a set for their own language.</li>
</ul>
<h3 name="Content_Packages">Content Packages</h3>
<p>The name of the JAR file might describe what it contains, but you can't be sure unless you view its contents. Let's use the browser package included with Firefox as an example. If you extract the files in <code>browser.jar</code>, you will find that it contains a directory structure much like the following:</p>
<pre>content
   browser
      browser.xul
      browser.js
      -- other browser XUL and JS files goes here --
      bookmarks
         -- bookmarks files go here --
      preferences
         -- preferences files go here --
.
.
.
</pre>
<p>This is easily recognizable as a content package, as the top-level directory is called <code>content</code>. For skins, this directory will usually be called <code>skin</code> and for locales, it will usually be called <code>locale</code>. This naming scheme isn't necessary, but this is a common convention to make the parts of a package clearer. Some packages may include a content section, a skin, and a locale. In this case, you will find a subdirectory for each type. For example, Chatzilla is distributed in this way.</p>
<p>The <code>content/browser</code> directory contains a number of files with <code>.xul</code> and <code>.js</code> extensions. The XUL files are the ones with the <code>.xul</code> extension. The files with <code>.js</code> extensions are JavaScript files containing scripts that handle the functionality of a window. Many XUL files have a script file associated with them, and some may have more than one.</p>
<p>In the listing above, two files have been shown. There are of course others, but for simplicity they aren't shown. The file <code>browser.xul</code> is the XUL file that describes the main browser window. The main window for a content package should have the same name as the package with a <code>.xul</code> extension. In this case, the package name is "browser" so we expect to find <code>browser.xul</code>. Some of the other XUL files describe separate windows. For example, the file <code>pageInfo.xul</code> describes the page info dialog.</p>
<p>Many packages will include a <code>contents.rdf</code> file, which describes the package, its author, and the overlays it uses. However, this file is obsolete and has been replaced with a simpler mechanism. This newer method is the manifest file mentioned earlier, and you will find these as files with the <code>.manifest</code> extension in the chrome directory. For instance, <code>browser.manifest</code> describes the browser package.</p>
<p>Several subdirectories, such as <code>bookmarks</code> and <code>preferences</code>, describe additional sections of the browser component. They are placed in different directories only to keep the files more organized.</p>
<h3 name="Skins_or_Themes">Skins or Themes</h3>
<p>Although the underlying code for Mozilla calls them skins and the user interface calls them themes, they're both referring to the same thing. The <code>classic.jar</code> file describes the default theme provided with Firefox. The structure is similar to the content packages. For example, examining <code>classic.jar</code>:</p>
<pre>skin
   classic
      browser
         browser.css
         -- other browser skin files go here --
      global
         -- global skin files go here --
.
.
.
</pre>
<p>Again, this directory structure isn't necessary and is used for convenience. You can actually put all the files in one directory at the top level and not use subdirectories. However, for larger applications, subdirectories are used to separate the different components. In the example above, a directory exists for theme related files for the browser and another for global theme related files. The global directory contains skin files that are general to all packages. These files will apply to all components and will be included with your own standalone applications. The global part defines the appearance of all of the common XUL widgets, whereas the other directories have files that are specific to those applications. Firefox includes both the global and browser theme files in one archive, but they can be included separately.</p>
<p>A skin is made up of CSS files and a number of images used to define the look of an interface. The file <code>browser.css</code> is used by <code>browser.xul</code> and contains styles that define the appearance of various parts of the browser interface. Again, note how the file <code>browser.css</code> has the same name as the package. By changing the CSS files, you can adjust the appearance of a window without changing its function. This is how you can create a new theme. The XUL part remains the same but the skin part changes independently.</p>
<h3 name="Locales">Locales</h3>
<p>The file <code>en-US.jar</code> describes the language information for each component, in this case for US English. Like the skins, each language file contains files that specify text used by the package for a specific language. The locale structure is similar to the others, so it won't be listed here.</p>
<p>The localized text is stored in two types of files: DTD files and properties files. The DTD files have a <code>.dtd</code> extension and contain entity declarations, one for each text string that is used in a window. For example, the file <code>browser.dtd</code> contains entity declarations for each menu command. In addition, keyboard shortcuts for each command are also defined, because they may be different for each language. DTD files are used by XUL files so, in general, you will have one per XUL file. The locale part also contains properties files, which are similar, but are used by script files. The file <code>browser.properties</code> contains a few such localized strings.</p>
<p>This structure allows you to translate Mozilla or a component into a different language by just adding a new locale for that language. You don't have to change the XUL code at all. In addition, another person could supply a separate package that applies a skin or locale to your content part, thus providing support for a new theme or language without having to change the original package.</p>
<h3 name="Other_Packages">其他的包</h3>
<p>    有一个特殊的包叫做 toolkit (或 global)。早在涉及 skins 我们就看了 global 文件。<code>toolkit.jar</code> 文件包含它对应的内容。这里有一些通用的对话框及定义。这里也包含了丰富的 XUL 组件(如 textboxes 及 buttons)的定义及功能。在 global\skin 目录下的文件定义了全部 XUL界面元素的默认外观。toolkit 包被所有 XUL程序使用。</p><h3 name="Adding_a_Package">Adding a Package</h3>
<p>Mozilla places the packages that are included with the installation in the <code>chrome</code> directory. However, they do not need to be placed there. When installing another package, you can place it anywhere on the disk, as long as a manifest file points to it. It is common to place packages into the <code>chrome</code> directory simply because it is convenient; however, they will work just as well from another directory or somewhere on your local network. You cannot store them on a remote site, unless the remote site is mounted through the local file system.</p>
<p>There are two <code>chrome</code> directories used for XUL applications: one is installed in the same place where the application is installed, while the other is part of user's profile. The former allows packages that are shared by all users while the latter allows packages to be created only for a specific user or users. Extensions, while installed in a separate extensions directory, are also usually user specific. Any manifest files located in either chrome directory will be examined to see which packages are installed.</p>
<p>In the next section, we'll look at how to refer to chrome packages using the chrome URL.</p>
<p>{{ PreviousNext("XUL Tutorial:Introduction", "XUL Tutorial:The Chrome URL") }} <span class="comment">Interwiki Language Links</span></p>
<p>{{ languages( { "es": "es/Tutorial_de_XUL/Estructura_XUL", "fr": "fr/Tutoriel_XUL/La_structure_XUL", "ja": "ja/XUL_Tutorial/XUL_Structure", "pl": "pl/Kurs_XUL/Struktura_XUL", "de": "de/XUL_Tutorial/XUL_Struktur" } ) }}</p>
恢复到这个版本