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 (http://optimoz.mozdev.org/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="http://www.w3.org/1999/02/22- rdf-syntax-ns#" xmlns:chrome="http://www.mozilla.org/rdf/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="http://www.w3.org/1999/02/22- rdf-syntax-ns#" xmlns:chrome="http://www.mozilla.org/rdf/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="http://www.mozilla.org/locales/e 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 several contents.rdf files. In a single theme (e.g., the modern.jar), you can see as many as eight manifests (for major component to which the theme applies). These two types of manifests -- the contents.rdf file, which typically describes a single package-component relationship; and the manifest.rdf file, which describes the package's relationship to all affected components -- are functionally equivalent. In both cases, the chrome registry reads all RDF/XML data and registers the package. Because the manifest data format is RDF/XML, you can use either type of manifest in your own package development, although using a single manifest.rdf is generally much easier, especially if you want to change the list of affected components of any other metadata later. The package manifests for content and new applications -- which may include new content, skin, and locale information -- have an identical syntax and a very similar structure, as you will see in the following sections. The manifest for a full Mozilla-based application like xFly describes the content, the skin, and the locale in a single file that sits at the top of that package. 6.2.1.3. Application manifests When you create new applications on top of Mozilla, you will often create new content, new skins, and your own localizable language elements, such as DTDs. For applications, the manifest must describe these parts of your application if Mozilla is to find and register them properly. [...]... Section 6.2 .4 for more information about this process 6.2 .3 Creating a Package The xFly sample package is a relatively straightforward arrangement of content, skin, and locale You have already seen how to set up most preliminaries you need to make it a package in Chapter 2, but this section will discuss the process in detail 6.2 .3.1 Setting up xFly To start working immediately with tools like XUL and. .. to create and test new packages without having to install them with installation scripts and manifests Some earlier xFly examples in this book already used this method The installed-chrome.txt file is a list of entries that point to package manifests Each line provides the chrome registry with a pointer to a manifest in which new software is described: new skin information, new packages, and new locales... between the packages, the package descriptions, and the chrome registry are shown in the following list • Manifests in the archives themselves • XPInstall, the technology that performs the downloading and resource installation • The chrome registry, the database of packages, and user information that is read and written to when new software is installed 6.2 .2.2 Registering packages as you develop them... focused manifests (Example 6-2 and Example 6-3), but all of the skin, content, and locale structures sit together in a single manifest.rdf file This manifest follows the Mozilla convention of introducing the package contents at the top and then expanding upon the basic listing of each separate sections, providing the necessary metadata about the items in the middle, and then listing the components... also a single file, is very similar to the manifest in Example 64 6.2 .2 Registering Packages Typically, registration occurs during installation, which is why the Section 6.3 section of this chapter goes into more detail about the specific methods and objects available for package registration The registration process deals with packages and package manifests, however, so the following two sections describe... your application, it's typical to work within a regular directory As you finish the application and make it available for distribution and installation, however, you may want to use one of the installation archive formats to package your work, such as a JAR file See the section Section 6.3 .1 later in this chapter for more details When your application is large and distributed in this way, the RDF-based... content is found in the directory chrome/xfly/content The next line points to the skin resources at chrome/xfly/skin, and so on Note that creating a single entry for the xFly skin and locating its resources underneath the xFly application directory (as opposed to a subdirectory in the modern and/ or classic JARs) means that the xFly skin will not change when the user changes skins If we had the same structure... on installation, as is typically done, and the second describes how to use a special file to register your work with Mozilla as you develop it so that you can view your work as it progresses 6.2 .2.1 Registering packages on installation Generally, the registration process is a transaction that takes place between your installation scripts, the chrome registry, and the manifests that describe the package... the local disk and alerting the chrome registry to the new files and their manifests The chrome registry then finds and reads those manifests If the information there is formatted correctly, then that information is added to the sum of package information that the chrome registry manages a single, overarching datasource of all packages in Mozilla, including skins, locales, overlays, and other software... rather than a Direct children of the overlay are associated with certain elements in the main browser (in this case, the of the Tools menu) and their contents are interpolated into the list of children there This file overlays an extra into the Tools menu In this case, the menuitem has an oncommand event handler that calls toOpenWindowByType a function for opening new . Chapter 6. Packaging and Installing Applications- P1 The previous chapters covered the basic parts. new Mozilla applications. 6. 2. Packaging Mozilla Applications Packaging simply means organizing your files into a Mozilla application structure. Packaging