Tài liệu Creating Applications with Mozilla-Chapter 6. Packaging and Installing Applications-P2 ppt

Chapter 6. Packaging and Installing Applications-P2
6.2.3.4. Overlaying Mozilla files into your application
In the previous section, we described how to use the XUL overlay
technology to put information from your application into the Mozilla
browser. When developers use overlays in this way, they usually add a
menuitem or a new UI to the browser that provides access to the
application.
But overlays can also add interface elements and other data from Mozilla
into the application itself. In fact, each component in Mozilla imports a lot of
its own user interface from such XUL overlay mainstays as
globalOverlay.xul, tasksOverlay.xul (the file into which the
xFly menuitem is overlaid), and navigatorOverlay.xul. As you can
see when you look at the main browser file, navigator.xul, shown in
Example 6-7
, most user interface is actually brought in from these reusable
overlays. A relatively small percentage of all that appears in the browser is
defined within that particular navigator.xul file.
Example 6-7. Overlays in navigator.xul
<?xul-overlay
href="chrome://navigator/content/navigatorOverlay.x
ul"?>
<?xul-overlay
href="chrome://navigator/content/navExtraOverlay.xu
l"?>
<?xul-overlay
href="chrome://navigator/content/linkToolbarOverlay
.xul"?>
<?xul-overlay
href="chrome://communicator/content/sidebar/sidebar
Overlay.xul"?>
<?xul-overlay

href="chrome://communicator/content/securityOverlay
.xul"?>
<?xul-overlay
href="chrome://communicator/content/communicatorOve
rlay.xul"?>
<?xul-overlay
href="chrome://communicator/content/bookmarks/bookm
arksOverlay.xul"?>
Of these overlays, those with the most value for application developers are
the communicatorOverlay.xul, which defines many of browser
menus; the tasksOverlay.xul, which adds the Tools menu and brings
in all of its application menuitems as well as a lot of important browser
functions like toOpenWindowByType and toNavigator (for returning
to the main browser window); and the globalOverlay (which is overlaid
into navigatorOverlay.xul, so it gets loaded there), which defines even more
general and low-level features like pop ups and functions for quitting the
application or setting tooltip text.
Once files are divided into subdirectories and the manifests for each
subdirectory, your application is technically a package -- although until you
compress it and create an install script, it's a package only for your computer
and the environment in which it was created. See the section Section 6.4

later in this chapter to see how you can use the file format and installation
information to make the xFly something you can put on a web server and
have users install with a single click on a web page.
6.2.4. The Chrome Registry
The chrome registry was briefly mentioned several times in this book. It
plays an important (but sometimes invisible) role in the way Mozilla
applications, including the Mozilla browser itself, deal with user
information, new components, skins, and other resources.

At the beginning of the book, you had to create RDF files that would
describe your application to Mozilla. Special entries also needed to be made
to the installed-chrome.txt file in the chrome application
directory. These entries are just two of the most common ways to address
the chrome registry, which is what Mozilla uses to persist configurable
aspects of the browser and its other applications.
6.2.4.1. Where is the chrome registry?
The chrome registry is not a single file and it's not stored in a single place.
Rather, it is a distributed collection of data and interfaces for data
manipulation. The data itself generally lives in RDF files, many of which are
in the chrome application directory. The chrome registry APIs --
principally nsIChromeRegistry -- are used by installation scripts when
they register new software, by the skin-switching UI, and by the language
selection facility. The chrome registry is the means through which packages
are registered.
In some cases, especially when you create and debug your Mozilla
application, you may want to edit the RDF files that make up the chrome
registry directly. But more often, you can use external scripts, inline
JavaScript, or the installed-chrome.txt file to get what you need
from the registry. Procedures for doing so are described in the section
Section 6.2.2
earlier in this chapter, and in the section Section 6.3.2 later in
this chapter.
6.2.4.2. Accessing the chrome registry in installation scripts
An install script is a required part of a software package like the xFly. The
two main functions of an installation script are the physical download and
installation of files in the package and registration of that software with the
chrome registry. Install scripts use functions from the XPInstall API to
install the files and functions from the chrome registry interface to handle
the latter, as seen in this snippet:

registerChrome(PACKAGE | DELAYED_CHROME,
getFolder("Chrome", "help"), "content/");
The registration process is typically something that happens between the
install initialization and the actual execution of the install:
initInstall( ) // initialize the overall
installation
// add items to installed using:
// addFolder, addDirectory, getFolder, and others
registerChrome(TYPE, dir, subdir)
performInstall( );
Scripts and the installation process, including the registration of installed
packages, are detailed in the next section.
6.3. Installing Mozilla Applications
Once your application is packaged, the next step is to create a cross-platform
installation, or XPI. A XPI is a special file archive that contains your
Mozilla package(s) and its own installation instructions. The relationship of
the various parts of the installation process -- the XPI itself, the internal
installation script, the trigger script that begins the installation, and the
Mozilla browser -- can be visualized in Figure 6-4
.
Figure 6-4. Installation process overview

6.3.1. The XPI File Format
Mozilla cross-platform installations use XPIs as the file format in which to
organize, compress, and automate software installations and software
updates. A XPI is a PKZIP-compressed archive (like ZIP and JAR files)
with a special script at the highest level that manages the installation. A
quick scan of the contents of a XPI file (which you can open using with any
unzip utility) reveals the high-level directory structure shown in Example 6-
8.

Example 6-8. Top level of the browser.xpi archive
install.js
bin\
chrome\
components
defaults\
icons\
plugins\
res\
Note that the high-level structure in Example 6-8
parallels the installed
browser's directory structure very closely. The bin directory at the highest
level of the archive corresponds to the Mozilla application directory. On
Unix, this directory is actually called bin, where all of the resources are
stored. On other platforms, the installation puts these resources in the
application directory itself.
In the case of the Mozilla browser, the XPIs manage the transfer and registry
of all components -- the chrome files in the JARs, the executables, the
default user information, and the libraries. As you will see in the installation
script, the contents of the archive are installed onto the filesystem in much
the same way as they are stored in the archive itself, although it's possible to
rearrange things arbitrarily upon installation -- to create new directories,
install files in system folders and other areas, or execute software that
handles other aspects of the installation, such as third-party installers.
6.3.1.1. XPI example
When the items to be installed are very simple, XPIs may contain nothing
more than a single executable and the install script itself, as shown in Figure
6-5. In this figure, the WinZip utility has been used to display the contents of
a XPI that installs a text editor on a Win32 system.
Figure 6-5. Simplest XPI archive

This example uses XPInstall technology to install something that may or
may not be a Mozilla application. The install.js script in Example 6-8

would look like this. In Mozilla application development, however, XPIs
often contain JAR files that are installed as new packages in the Mozilla
distribution. To make a XPI for your package, use any zip software
(applications or extensions that will be part of the main Mozilla distribution
are required to use the free zip utility from InfoTools so that they can be run
as part of the build process) to archive your files.
6.3.1.2. JARs versus XPIs
Technically, only the internal installation script distinguishes JARs and
XPIs. However, Mozilla treats them differently. Since JARs do not include
this installation script, they cannot install full content or applications by
themselves. In this case, "content" means XUL, XBL, or JavaScript files that
have script access to XPCOM. Files of this kind that are in JARs are denied
access to XPConnect and are not registered as content in the chrome
registry. JARs are used primarily to install locales, or language packs, and
skins.
Skins that contain scripts and bindings (see the section Section 4.5.3
and the
Evil Skins
sidebar, both in Chapter 4) are seen more as chrome content and
must be installed in XPIs if they are to be fully functional. Like executables
that are fetched from the Web, XPIs can cause trouble when downloaded by
unprepared users since the software in XPIs are given the same privileges on
the Mozilla platform that the browser chrome itself has.
The characteristics and usage of an XPI are:
•
Has an install.js file

•
Can install anything via XPInstall API
•
PKZip-compressed
•
May contain one or more JAR packages
•
Mozilla installation
•
Used for new packages
The characteristics and usage of a JAR are:
•
Contains only the resources themselves
•
Installed with an external script
•
May be installed inside a XPI
•
PKZip-compressed
•
Themes
•
Languages packs
•
Storage archive for installed components
Mozilla uses the presence of this internal installation script and not the file
suffix (which can be changed easily enough) to determine what type of
archive it is. Accordingly, JARs are most often used to install new themes
and new language packs, which can be done by using just a brief trigger
script on a web page loaded into Mozilla. When they contain new chrome --

new XUL and JavaScript that will access the Mozilla objects via XPConnect
-- JAR files must be put within a XPI that can register them properly.
6.3.2. Installation Scripts
Most new packages in Mozilla are installed by means of installation scripts.
These scripts are written in JavaScript. Unlike regular web page JavaScript,