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

Chapter 6. Packaging and Installing Applications-P1
The previous chapters covered the basic parts of building an application.
Now that you've seen how to create an application with XUL, CSS, and
JavaScript that can be used on your local computer, we will show you how
to turn your program into something that can be installed by other users.
This chapter discusses the technologies Mozilla provides for packaging and
installing applications.
Until your project is packaged for distribution, it can't be fully considered a
finished application (unless it was designed to work only on the computer
where it was created). Making your application distributable, installable, and
registrable allows others to use what you have created.
This chapter is divided into four main sections. It starts with a quick
overview of the basics of packaging and installing applications. The second
section provides details about how to get your application packaged and
described so that Mozilla recognizes what it is. The next section specifies
how to put your package into a cross-platform installation file that can be
installed over the Web onto other machines. The last section provides tips
for customizing how your application will look once it is installed.
6.1. Packaging and Installing Overview
Several different pieces comprise Mozilla's distribution technology. In fact,
Mozilla may have a few more moving parts than other packaging systems
because it needs a way to package and install new software uniformly across
several different platforms. Figure 6-1
shows the major components of
Mozilla's packaging system outlined in black.
Figure 6-1. Mozilla packaging components

As you can see in Figure 6-1
, the Cross-Platform Installer (XPI), pronounced
zippy or X-P-I, is the archive format used to distribute Mozilla applications.
The XPI file contains a script that downloads and installs the application.

The package inside the XPI has a manifest that is used to register the new
Mozilla-based software with the Mozilla chrome registry.
When a XPI contains a Mozilla-based package such as the xFly sample
discussed in Chapter 2
and the following chapters, the installation script also
takes care of the package registration process, described in the Section 6.2.2

section later in this chapter. Example 6-1
shows a simple installation script
and the kind of information it contains. The Section 6.3.2
section, also later
in this chapter, discusses other scripts that may need to be used in the
installation process, such as trigger scripts.
Example 6-1. Package installation script
var myFile = "xFly.jar";
initInstall( // initialize the
installation
"Install xFly", // display name
of installation
"xFly", // package name
"0.0.1", // version of
install
1); // flags - an
optional argument,
// reserved for
future use
f = getFolder("Chrome"); // specify a
target directory
setPackageFolder(f);
addFile(myFile); // add software

to the installation
registerChrome(
PACKAGE | DELAYED_CHROME, // chrome switch
(i.e., type)
getFolder("Chrome","xFly.jar"), // destination of
package
"content/xFly/"); // location of
manifest in package
if (0 == getLastError( )) // if there have
been no errors:
performInstall( ); // install
"xfly.jar"
else // otherwise
cancelInstall( ); // cancel the
installation.
The installation process requires a few different steps. First an installation
must be initialized. Then the software to be installed is added to the
specified target directory. Finally, packages in the installation are registered.
At this point, the application is installed on a user's computer.
When you install new packages or Mozilla-based software, the chrome
registry on the Mozilla side brokers the deal -- reading the manifest,
executing the installation script(s), and updating the package information
that it maintains internally (storing this information using RDF).
The relationship of the packaging, installation, and registration -- and all
pieces involved -- may seem a little complex and idiosyncratic at first, but
bear with it. The upshot of this powerful but somewhat diffuse packaging
technology is that you can bundle your software, put it on a server, and have
users install it by simply clicking a link on a web page when using Mozilla.
It is possible to use this packaging system to bundle any sort of application
or extension to an existing Mozilla application. You can install a XPI that

adds functionality to the Mozilla browser, such as Mouse Gestures
( ), which enables the execution of
common browser commands with mouse movements. You can package new
Mozilla development tools and libraries like JSLib (see Chapter 5). You can
also create installations for entirely new Mozilla applications.

6.2. Packaging Mozilla Applications
Packaging simply means organizing your files into a Mozilla application
structure. Packaging your application is required to make it installable and to
make it something that Mozilla recognizes as one of its own. Whether your
Mozilla-based becomes a part of an existing Mozilla application, like Mouse
Gestures, or will exist as a standalone application, like JabberZilla, you will
need to package it.
When you are done with this packaging section, package your Mozilla-based
applications in the same way that we packaged the xFly example in Chapter
2. This chapter describes the manifests and other necessary files. Then the
Installation section shows how you can put your package in a XPI file and
create installation script(s) so it can be distributed and installed.
6.2.1. Package Manifests
All new packages must have manifests describing their contents, skin
information, and locale information. These manifests are formatted in RDF,
which makes them easy to combine with the RDF data that makes up the
chrome registry and makes it easy to fit the package into the Mozilla
software. There is some flexibility about where in the package the manifest
must appear, but the registration process must find and read it regardless of
where it is.
The installation script points out the manifest locations so the package can
be registered properly. Note that manifests appear in JARs, but they do not
appear in XPIs, since the latter is a temporary file that gets deleted once the
files it contains, including JARs, are installed (see the Section 6.3

section
later in this chapter for more information about XPI install files).
6.2.1.1. Theme package manifests
Example 6-2
shows a manifest for a new theme to be installed in Mozilla. It
is simple because it describes only one type of package, the "fly skin," and
the existing component it interacts with, the communicator -- the default
Mozilla browser (the syntax and structure is the same for all manifests,
however). The manifest says, in effect, this is what I have here (the metadata
about the theme -- its name, a description, etc.), and this is what it affects
(the list of chrome:packages to which the theme should be applied).
Example 6-2. Simple theme package manifest
<?xml version="1.0"?>
<RDF:RDF xmlns:RDF=" />rdf-syntax-ns#"

xmlns:chrome="
<!-- List all the skins being supplied by this
theme -->
<RDF:Seq about="urn:mozilla:skin:root">
<RDF:li resource="urn:mozilla:skin:flyskin/1.0"
/>
</RDF:Seq>

<!-- Fly Skin Information -->
<RDF:Description
about="urn:mozilla:skin:flyskin/1.0"
chrome:displayName="Fly Skin"
chrome:author="frillies"
chrome:description="shimmering, purple/black,
hairy">

<chrome:packages>
<RDF:Seq
about="urn:mozilla:skin:classic/1.0:packages">
<RDF:li
resource="urn:mozilla:skin:classic/1.0:communicator
"/>
</RDF:Seq>
</chrome:packages>
</RDF:Description>
</RDF:RDF>
6.2.1.2. Language pack manifests
When you look at a package manifest that describes a new locale, as shown
in Example 6-3
(which is for a German language pack in Mozilla), you see a
similar structure. Again, the manifest describes the new package first and
then lists the existing components to which this new package applies.
Example 6-3. Locale package manifest
<?xml version="1.0"?>
<RDF:RDF xmlns:RDF=" />rdf-syntax-ns#"
xmlns:chrome="
<!-- list all the skins being supplied by this
package -->
<RDF:Seq about="urn:mozilla:locale:root">
<RDF:li resource="urn:mozilla:locale:en-DE"/>
</RDF:Seq>
<!-- locale information -->
<RDF:Description about="urn:mozilla:locale:en-DE"
chrome:displayName="English (German)"
chrome:author="mozilla.org"
chrome:name="en-DE"

chrome:previewURL=" />n-DE.gif">
<chrome:packages>
<RDF:Seq about="urn:mozilla:locale:en-
DE:packages">
<RDF:li resource="urn:mozilla:locale:en-
DE:communicator"/>
<RDF:li resource="urn:mozilla:locale:en-
DE:editor"/>
<RDF:li resource="urn:mozilla:locale:en-
DE:global"/>
<RDF:li resource="urn:mozilla:locale:en-
DE:messenger"/>
<RDF:li resource="urn:mozilla:locale:en-
DE:navigator"/>
</RDF:Seq>
</chrome:packages>
</RDF:Description>
</RDF:RDF>
Note that in Example 6-3
's package manifest, all major components are
affected by this new locale package. When the package is installed and the
manifest is read, the chrome registry is made aware of a German language
pack that it can use to display German in the interface of each Mozilla
component.
contents.rdf Type Manifests
Package manifests are an area where Mozilla browser itself may not be the
best model for learning about the best application development practice.
Mozilla is such a large and modular application that it uses several manifests
instead of one application-wide manifest.rdf file.

Although they have the same format, these distributed manifests are found in