# Appendix B. Development Tools- P1

Chia sẻ: Thanh Cong | Ngày: | Loại File: PDF | Số trang:17

0
45
lượt xem
3

## Appendix B. Development Tools- P1

Mô tả tài liệu
Download Vui lòng tải xuống để xem tài liệu đầy đủ

Appendix B. Development Tools- P1 Cuốn sách này mô tả cách tạo ra các ứng dụng bằng cách sử dụng Mozilla. Nói chung, tất cả các phần đó đi vào một ứng dụng (bao gồm cả XUL, CSS, XBL, và DTD tập tin) cần phải được xây dựng bởi bàn tay kể từ khi không có công cụ phát triển làm sẵn hoặc các ứng dụng phát triển hoàn chỉnh có sẵn mà có thể làm cho các quy trình hướng dẫn sử dụng dễ dàng hơn. Tạo tất cả những tập tin này bằng tay là một cách tuyệt vời...

Chủ đề:

Bình luận(0)

Lưu

## Nội dung Text: Appendix B. Development Tools- P1

1. Appendix B. Development Tools- P1 This book describes how to create applications using Mozilla. Generally, all parts that go into an application (including XUL, CSS, XBL, and DTD files) need to be built by hand since no complete ready-made development tools or development applications are available that would make these manual processes easier. Creating all these files by hand is a great way to familiarize yourself with the way Mozilla works, and becoming more familiar with the inner workings of a Mozilla application certainly helps you see how the various parts fit together. Once you are comfortable creating these files by hand, using the platform becomes much easier and Mozilla fulfills its promise as a rich application development framework. Development tools are important, though, and platforms like Mozilla can't obtain the sort of developer base they deserve until tools that make application creation easier are available. Although some people want to learn everything there is to know about creating applications with Mozilla, many simply want to create something without a lot of fuss. Mozilla does not yet have a full set of development tools, but currently several development projects help with part of the application creation process. These tools don't make up a full-featured development environment, but they are useful. They also point the way to an area in Mozilla development that has a bright future and is worth watching. This appendix describes some of the new tools -- including XULKit, Patch Maker, the DOM Inspector, the JavaScript Debugger, and MozillaTranslator
4. the main browser that opens this new application), and localizable data in the mozref.dtd file in the locale subdirectory. In addition to these files, the XULKit script creates contents.rdf files that describe each package, some Makefiles that instruct the Mozilla build process how to integrate this application into the build (which is a later step and not necessary to run the application), and an install.js file that executes the installation of this application when it appears in a XPI. (See Chapter 6 for more information about XPI, Mozilla's cross-platform installation file format.) If you look at Example B-1 -- xul-app.tpl, which comes with the distribution of new-from-template.pl -- you can see how easy it is to fill out the basic information and create your own template. Example B-1. Sample application template # load default template for a XUL app include "${top_wizard_dir}templates/xul-app.tpl" # short app name (can not contain spaces.) # until http://bugzilla.mozilla.org/show_bug.cgi?id=75670 is fixed, this needs # to be all lowercase. app_name_short=xulsample # long app name (spaces are OK.) app_name_long=Sample XUL Application (generated from sample.xul-app.tpl) 5. # name as it should appear in the menu app_name_menu=Sample XUL App # version to tell the .xpi installer app_version=1.0 # author, used in various chrome and app registration calls app_author=mozilla.org # size of the package when installed, in kilobytes. # this number is used by the install.js script to check for enough disk space # before the .xpi is installed. You can just guess for now, or put 1, and fix it # in install.js before you make your .xpi file. install_size_kilobytes=1 You can adapt the xul-app.tpl for your own purposes or use the sample.xul-app.tpl that is already filled out. Table B-1 details different options for new-from-template.pl. Table B-1. Options for the new-from-template.pl script Option Description Recursively deletes the output -d directory before starting; requires the -f option. 6. Option Description Forces file overwriting in the output -f directory. Displays a description of the specified template with -o. The template will not be processed. The template description is taken from the -h value of the template_description variable in the template file. template_descriptions provided by the main template file's template file(s) are not displayed. Generates the template into the directory specified by DIRECTORY. If this directory already exists, new- from-template.pl will fail. This failure prevents you from -o DIRECTORY accidentally overwriting an existing application. Use the -f option to continue anyway. Use -fd to force DIRECTORY to be deleted before the template is processed. 7. Option Description Processes the template specified by -t TEMPLATE TEMPLATE. This file is usually in the my/ sub-directory, ending in .tpl. -? Shows usage information and exits. B.1.1.1. XULKit templates Two different application templates come with new-from- template.tpl, each with its own empty and sample versions. Example B-1 shows sample.xul-app.tpl in its entirety. The other template, xpcom-component.tpl, uses information you supply to create the framework for an XPCOM component. As with xul-app.tpl, the template comes with a sample that's already filled out. This script creates an IDL file, a header file, and a stubbed-out CPP file in an application subdirectory structure you can use to begin coding your XPCOM component. In the xpcom-component.tpl, many variables do not need to be changed, but required fields are set aside in the template: # variables the user's .tpl file MUST declare required_variables =${component_name}, ${implementation_guid}, \${interface_name}, ${interface_guid} 8. Using this script, you can fill out a subset of the template with the information XPCOM requires, and XPCOM will generate the basic files you need, as Example B-2 shows. Example B-2. Sample XPCOM component template # include default values include "${top_wizard_dir}templates/xpcom- component.tpl" component_name = SampleComponent implementation_guid = c6793b0c-1dd1-11b2-a246- 92bf95c9d097 interface_name = tstISampleComponent interface_guid = d03ea960-1dd1-11b2-9682- 81ecad6a042a B.1.2. makexpi.pl Script In addition to the template-generating script described above, a second script takes your working application and creates an installable package, or XPI, out of it. This way, you can distribute it to others in the same way the various components of the Mozilla browser are distributed and installed when you use the Mozilla installer. This script, makexpi.pl, takes an application directory as input and generates an XPI archive. It also manifests for various parts of your application, the installation script that goes inside this archive, and even the installation web page itself. While new-from-template.pl is designed to help you start your application, makexpi.pl takes your locally
9. developed application and makes it into a package that can be distributed to other users and installed via the Web. To use makexpi.pl, point it at a configuration file that you have edited to point at your application directory: makexpi.pl [-c ] [-d] [-r ] [-?] For example, to create a XPI out of your MyApp application directory, in which you created a file called MyApp.conf that defines the variables makexpi.pl needs, execute the script as follows: perl makexpi.pl -c ~/appdev/MyApp/makexpi.conf -r 0.9.9 A makexpi.conf file defines the variables makexpi.pl needs to know about. Example B-3 shows an example of this file. Example B-3. makexpi.conf file # directory where xpi should be created workdir = /home/rginda/src/xulkit/sample-app/ # directory where jar.mn is mndir = ${workdir}/sampleapp/resources/ # location of templatized install.js file installfile =${xulkit_dir}/templates/xpi/install.js # directory where mozilla's make-jars.pl and friends are
10. mozcfgdir = ${xulkit_dir}/bin/ # name of resulting xpi file xpifile =${app_name_short}-${revision}.xpi Table B-2 lists the options that are recognized by makexpi.pl. Table B-2. Options for the makexpi.pl script Options Description -c FILE Specifies the configuration file to use. Doesn't remake the JAR, but -d packages the existing contents of the chrome/ directory as an XPI. Specifies the value of the${revision} variable. This specification overrides any value specified in the -r REVISION configuration file and defaults to "0.01". Typically, this number is used in the install.js script and as part of the XPI filename. -? Shows usage information and exits. When you run the script against the configuration file, you end up with two separate pieces -- the XPI in which your application and its installation script are stored and a web page that you can post on a server to guide the XPI's installation. As described in Chapter 6, the web page interacts with the XPI's