Back to XUL: Introduction and Preparation - More setup information
(Page 4 of 4 )
The directory structure used here represents a simplified version of that used by Mozilla, although Mozilla also makes use of packaged Java Archive files (.JAR). Creating the application in this way makes testing it a little trickier; you need to create the interface file first so that you know which entities you need to put in your DTD, however, you need to register the DTD in the chrome registry before your interface file can read the entities in it, and hence before it will work.
You will also need to describe the application using a contents.rdf file, another file that helps build the chrome registry that ensures Mozilla has all of the information required to run your application. Once we have created the interface and contents files, you will see information taken from the contents.rdf file and added to the chrome.rdf file, information such as the name of the application, the name of the developer and the version number.
The chrome registry acts like a list that specifies the locations of the files used in your application. DTDs, stylesheets and other files are accessed using a chrome URL which points the application to the files it needs. The URLs can be hard-coded into files, such as the chrome.rdf file, or entered into a command line prompt or the browser's address bar to launch the requested file. Generally, the latter format is used to open your application, while the hard-coding method is used by the application to locate the associated files (such as stylesheets and DTDs.)
The registry itself is just a simple text file (called chrome.rdf) that contains a list of the physical paths of every aspect of chrome in use. It also contains information about the different components. This file is regenerated each time the application is run, and you will know whether you have successfully added your files when you see a section regarding your application appear in this file. It takes information for the registered components from another simple text file (called installed-chrome.txt) that can be edited to ensure components you add are registered and available to the application.
For the sake of the flow of the article series, we will create our interface file first, and the associated, required files afterwards. This will mean that you won’t be able to test the interface right away, but don’t worry, once everything is in place and registered you can test the application and correct the inevitable errors. Usually, these will be typos or other such simple mistakes.
I hope this has been an easy introduction for those that have not been exposed to XUL or a useful refresher for those that have. Article two will walk you through creating the interface file.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
