10.2. The Mozilla Content Model
One theme of this book -- and a general goal of the Mozilla development environment -- is that developers can create real applications using many of the same technologies they use to create a web page. The Gecko rendering engine, sitting at the heart of Mozilla and happily rendering web content, XML files, XUL interfaces, and whatever else they can support, is what makes this type of development possible. But how does Gecko know what to render and how? How can RDF data be handed over so that Gecko knows how to draw it?
When a browser uses the same engine to draw everything -- its own interface as well as the various kinds of content it supports -- that engine treats everything as content. Gecko needs a way to understand all the various parts of the Mozilla browser itself -- such as the sidebar, the toolbars, and the mail folders and mail messages -- as resources it can render and display in the Mozilla chrome. This approach to the Mozilla application interface is called the content model.
In Mozilla's content model, XUL documents and other interface resources are transformed into RDF when they are read. Each chunk of content is represented as a separate RDF datasource (see the next section, Section 10.2.1, for more information) and is then fed to the XUL Content Builder and rendered as the actual bits on the screen, as Figure 10-9 shows.
As you can see in Figure 10-9, the content model can be complex. The XUL documents in Figure 10-9 are files such as navigator.xul, which defines the main browser window's basic layout; the RDF documents include files like help-toc.rdf, which defines the Mozilla Help viewer's table of contents. The list of mail folders and accounts shown in Example 10-5 are part of the built-in data that Mozilla renders into browser content.
Whatever the source, the content model gets everything processed in-memory as RDF so that any data can be combined and formatted into XUL or other interface code. All sources of RDF data are called datasources.
10.2.1. Datasources
A datasource is a collection of related, typically homogenous, RDF statements. A datasource may be a single RDF file like localstore.rdf, a combination of files, or RDF structures that exist only in memory (as discussed later).
In Mozilla, datasources represent the messages in your email inbox, your bookmarks, the packages you installed, your browser history, and other sets of data. Datasources can be combined easily (or "composed," which is where the term "composite datasource" comes from).
10.2.1.1. A datasource example: mailboxes
Several datasources describe all the folders and messages in Mozilla's email. A root datasource called msgaccounts describes which mail servers and accounts are present. Separate datasources then represent each account separately. These datasources are composed to create the entire email storage system. The higher levels of this content structure look like Example 10-5.
Each direct child of the root msgaccounts:/ is a mail server. This portion of the graph shows two Mozilla email accounts that are the primary children: imap://[email protected] and mailbox://[email protected]. These two accounts are entirely different datasources that can exist on their own. The content model for email actually extends much lower than what is represented in this outline. It uses RDF to represent the data all the way into the actual message lists.
10.2.1.2. Types of datasources
As you may have already inferred, email accounts are not actually RDF files. Mozilla provides a custom RDF map of all email accounts and messages and the content model represents the accounts and their relationships to one another as RDF so they can be integrated and rendered properly. The interface to this custom mail RDF map makes it possible to display a list of messages and mailboxes in a <tree> template.
Another example of a datasource, the in-memory-datasource, doesn't come from an actual RDF file. When an in-memory datasource is created, it doesn't contain data. However, data can be inserted into it and stored in memory until the datasource is destroyed. In-memory datasources frequently represent ephemeral data like search results. Other basic datasource types are described in Table 10-2.
Table 10-2. Types of datasources
|
Type |
Description |
|---|---|
|
Local datasource |
A local datasource is an RDF graph contained in an RDF/XML file on a local disk. All RDF files in the chrome registry (e.g., all-packages.rdf in the chrome directory, which keeps track packages installed in Mozilla) are local datasources. |
|
Remote datasource |
RDF can be accessed locally or remotely. A remote datasource is an RDF/XML file stored on a server and accessed with a URL. |
|
In-memory datasource |
An in-memory datasource exists only in memory during a Mozilla session. In-memory datasources are built with assertions, statements that build an in-memory data model by adding resources, properties, and value to those. |
|
Built-in datasource |
These unique, prefabricated datasources represent something used often in Mozilla, such as a built-in filesystem datasource and a history datasource. |
|
Composite datasource |
A composite datasource may be a combination of any of the datasources previously listed. RDF allows you to merge different graphs. |