Creating Applications with Mozilla-Chapter 9. XUL Templates- P2

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

lượt xem

Creating Applications with Mozilla-Chapter 9. XUL Templates- P2

Mô tả tài liệu
  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 9. xul templates- p2', công nghệ thông tin, kỹ thuật lập trình 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 9. XUL Templates- P2

  1. Chapter 9. XUL Templates- P2 Example 9-6. Tree template code of Figure 9-3
  2. object="?location"/> One major difference between this example and earlier ones is that Example 9-6 has three columns. The color data cannot be used for style in this tree scenario because trees do not support CSS data styling.
  3. All generated data can be sorted automatically by clicking on the column headers. Besides the tree parent element in the XUL, the other main difference between this template and the one used with a listbox in Example 9-4 is the structure directly beneath , where is replaced by . 9.2.4. Multiple Rules Tree In Example 9-6, empty cells were left blank. Sometimes situations demand that missing data be represented by something other than whitespace, such as a special character or marker. Fortunately, multiple tags can exist in a template, as shown in Example 9-7. Alternate rule tags allow the display of missing data with other, more general rules. Using alternate tags, you can set up templates that look like conditional blocks; if the first rule is not satisfied, then the second rule is tried, followed by the third, and so on. Example 9-7 shows this structure of multiple rules. Example 9-7. Tree template with rules
  4. predicate="" object="?color"/>
  5. predicate="" object="?label"/> In contrast to Example 9-6, Example 9-7 moves ?location from to in the first in the template, making it a required match. To avoid breaking the template -- because not all objects in the RDF file have a ?location value -- you need to make a
  6. backup plan for generating this template when it encounters an object without a ?location. This backup can be a second set of more broadly defined conditions, so that objects that "fall out" of the first condition are picked up by the next. See the next section for an example of using different sets of rules. The most important inclusions to Example 9-7 are the container="?uri" and child="?listitem" attributes on the . These attributes specify which container you should apply multiple rules to, and the child is for the objects in a container that must be checked. Adding these attributes keeps the template from dying when the data doesn't meet the first rule. The second rule, which doesn't have a or to identify it, is used only when a ?location isn't present. Instead, it automatically fills in that cell with a hyphen (Figure 9-4). Figure 9-4. Tree template with hyphen rule
  7. As you can see at the top of Example 9-7, the template datasource is a file called 10-4.rdf, which contains all the data listed in Example 10-4 (in the next chapter). If you save the template listed in Example 9-7 and the RDF listed in Example 10-4, you can display the tree shown in Figure 9-4. 9.2.5. Multiple Rules Menubar Example 9-7 is a template that contains three rules. In Example 9- 8, where a is shown with three rules, all possible menu scenarios must be covered. Table 9-2 provides a list of these scenarios. Use scenarios like this to make sure you have content that can be created for all the data you need represented. Table 9-2. Scenarios used for building template rules Scenario Description A has a label and contains a . Inside it are two s: Scenario 1 ?location and ?color. The Horn Fly, Carrion Fly, and Office Fly fall into this category. A has a label and contains a . Inside it Scenario 2 is one : ?color. The Common House Fly, Stable Fly,
  8. Scenario Description and Face Fly fall into this category. A has a label and contains a . Inside there is no (only Scenario 3 ). Horse and House fall into this category. The scenarios in Table 9-2 can be translated directly into three template rules. Scenario 1 would be the first rule because it uses the most content. Scenario 2 would be the second rule because it's missing only the location. Scenario 3 will be the final rule because it doesn't have a location or color. Example 9-8. Menubar template with three rules
  9. predicate="" object="?label"/> As you can see, Example 9-8 is a long XUL section. When you create the first rule, it becomes easier, though, because the subsequent rules are just versions of the rules above them. Figure 9-5 shows how this template draws the data in the 9-5.rdf datasource. Figure 9-5. Menubar template with menus
  10. 9.3. Using Other XUL Tags for Templates Almost any XUL element that can be used as a container can use a template to define its inner content. Example 9-9 shows a used as the start for a XUL template. Templates like this can create content that doesn't look as tabular or ordered. Example 9-9. Template implemented in a box with buttons as content
  11. predicate="" object="?list"/>
  12. The content generated in Example 9-9 includes three s and a inside a vertical . The template building process is repeated for every object in the RDF graph, and some buttons are left blank. The result is a window full of buttons for each piece of data, which may get you started making heads-up displays or panel-like applications for templates, such as flight simulators. Once you understand the basics of templates, it is fun to see what kind of XUL you can generate from it, such as games that need to render content on the fly, spreadsheets, database front ends, or other data-driven application user interfaces.


Đồng bộ tài khoản