Creating Applications with Mozilla-Chapter 10. RDF, RDF Tools, and the Content Model -P2

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

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

Tham khảo tài liệu 'creating applications with mozilla-chapter 10. rdf, rdf tools, and the content model -p2', công nghệ thông tin, quản trị web phục vụ nhu cầu học tập, nghiên cứu và làm việc hiệu quả

Chủ đề:

Nội dung Text: Creating Applications with Mozilla-Chapter 10. RDF, RDF Tools, and the Content Model -P2

  1. Chapter 10. RDF, RDF Tools, and the Content Model -P2 This file's root resource is an urn:root, which is the conventional name for root nodes in Mozilla's RDF files. When rendering RDF files, defining a root node for processing the document can be useful -- especially when building templates. This root node can be entered as the first item in the file: Root sequence Next, a generic tag needs to be used to specify a sequence of "fly" data. As in Example 10-2, is used as a list of fly types. This tag is a generic name because of the way XUL templates process lists of RDF data. If a list of data has sublists, as in the following examples, then they must use the same tag name to recurse correctly for the data they contain.
  2. Example 10-2 represents all the information given in the first paragraph of the text example: "There is a jar set up with the name urn:root. Inside of it there are two types of flies, listed as House and Horse." Example 10-2. RDF root sequence
  3. An RDF sequence resides with its list of resources inside . Here, shorthand RDF specifies a label with the fly:label attribute. The ID attribute within this sequence is actually a pointer to the main definition of the resource described by an about attribute of the same value. The about attribute includes a # in its identifier, much like HTML anchors use to refer to . For example, ID="Horse" points to about="#Horse" elsewhere in the file, allowing you to add to the description of any element with new properties and resources. Secondary sequences and literals The Horse and House resources need to be defined next. Example 10-3 shows the creation of Horse from the second paragraph. The process for creating House is almost identical. Example 10-3. The Horse sequence
  4. Here the shorthand RDF definition continues to use only the attributes. Again, a is defined and the items inside it are listed. The listed values have multiple attribute values, all of which are RDF literals. In longhand with RDF showing all literals, the last item would be written out as follows:
  5. Horn Fly red Kansas The two different namespace literals are both resource attributes. haematobia_irritans is used as the resource identifier because it is a unique value among all data. Laying out the data in the same pattern gives you the final, full RDF file in Example 10-4. Example 10-4. Entire RDF file
  6. fly:label="Stable Fly" fly:color="black"/>
  7. Example 10-4 shows the RDF data used in several template examples in Chapter 9. Example 9-4 includes the 10-4.rdf datasource, as do many of those templates. You can copy the data out of Example 10-4 and into a file of the same name to use as a datasource.
  8. 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. Figure 10-9. Diagram of Mozilla's content model
  9. 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
  10. 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). 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. Example 10-5. Content model of email datasources msgaccounts:/ +-- --> imap:// | +-- rdf#IsServer --> "true" | +-- -->
  11. | imap:// | +-- rdf#TotalMessages --> "4" | +-- rdf#IsServer --> "false" | +-- rdf#MessageChild --> | imap_message:// | +-- rdf#MessageChild --> | imap_message:// | +-- rdf#MessageChild --> | etc... | +-- --> mailbox:// | +-- rdf#IsServer --> "true" | +-- -->
  12. | mailbox:// | +-- rdf#TotalMessages --> "2" | etc... 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:// and mailbox:// 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. 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 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
  13. represent ephemeral data like search results. Other basic datasource types are described in Table 10-2. Table 10-2. Types of datasources Type Description 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- Local datasource packages.rdf in the chrome directory, which keeps track packages installed in Mozilla) are local datasources. RDF can be accessed locally or remotely. A remote datasource is an Remote datasource RDF/XML file stored on a server and accessed with a URL. An in-memory datasource exists only in memory during a Mozilla session. In-memory datasources are built with In-memory datasource assertions, statements that build an in-memory data model by adding resources, properties, and value to those.
  14. Type Description These unique, prefabricated datasources represent something used Built-in datasource often in Mozilla, such as a built-in filesystem datasource and a history datasource. A composite datasource may be a combination of any of the datasources Composite datasource previously listed. RDF allows you to merge different graphs. 10.3. RDF Components and Interfaces Once you are comfortable using XUL templates to display RDF data (see Chapter 9), you should explore the various ways to create and change that data. In Mozilla, data is generally RDF, since all data in Mozilla is either represented formally in RDF or passed through the RDF-based content model for display. Use the tools described in this section to manipulate RDF and the data it represents. Mozilla has a great set of interfaces for creating, manipulating, and managing RDF, and it also provides ready-made RDF components that represent datasources used in Mozilla. Think of RDF interfaces as ways to manipulate RDF directly and of RDF components as sets of the interfaces already associated with a particular kind of data, such as bookmarks. Interfaces tend to deal with the RDF model itself, without regard to the kinds of data being handled, while RDF components give you control over specific
  15. Mozilla data. See the next two sections for more information on RDF interfaces and components.



Đồng bộ tài khoản