Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống
1
/ 20 trang
THÔNG TIN TÀI LIỆU
Thông tin cơ bản
Định dạng
Số trang
20
Dung lượng
217,71 KB
Nội dung
xsl:include and xsl:import Syntax These two elements share almost the exact same syntax: <xsl:import href=”address” /> <xsl:include href=”address” /> The href attribute specifies the URI of the stylesheet that you wish to import or include, respectively. They can be the children of the top-level element only, and they can have no children. If they are used, they must be the first children of the root element. Specifically, no child element of the root can precede xsl:import except xsl:include, and no child element of the root can precede xsl:include except xsl:import. xsl:apply-imports This element is used to override the default behavior of XSLT concerning imported stylesheets. By default, an imported stylesheet template is used only if there are no tem- plates of the same name defined in the main stylesheet. With xsl:apply-imports, you can specifically request that an imported template be applied from within a template of the same name. <xsl:apply-imports/> This element can’t have children, and the only valid parent is xsl:template. Sorting XSLT gives you a mechanism for sorting data. Of course, you can also sort at the SQL level. Generally speaking, it is more efficient to sort at the SQL level than at the XSLT level. There will be cases, though, in which you will need to sort by using XSLT. This section defines the syntax for the xsl:sort element and gives examples of it’s use. xsl:sort Syntax The xsl:sort element changes the default sorting. By default, elements are presented in document order. However the elements are sequenced in the document in the order in which they are output. The xsl:sort element allows the order to be changed to some other kind of sorting, typically alphabetic or numeric and based on some prop- erty of the elements to be sorted. <xsl:sort select = “sort_expression” lang = “” data-type = “text” | “number” | “other_processor_supported_type” order = “ascending” | “descending” case-order = “upper-first” | “lower-first” /> Table 13.31 lists the attributes. 340 Chapter 13 Table 13.31 xsl:sort Attributes ATTRIBUTE NAME select The expression that is evaluated for each node. Results of evaluations determine sort order. lang RFC 1766 language code for the language used in determining order. The default is the system language. data-type When set to “number”, sorting is done numerically (2 precedes 100). When set to “text”, sorting is done alphanumerically (100 precedes 2). Any other types must be supported by the XSLT processor. The default is “text”. order Determines the direction of the sort. The default is “ascending”. case-order Determines whether lowercase letters precede uppercase letters or vice versa. Default is language- dependent. In English, uppercase precedes lowercase. Examples The most important thing to remember when using the xsl:sort element is that numeric sorts aren’t the same as alphanumeric sorts. Since the number 1 precedes the number 2, 1,000 will precede 2 in an alphanumeric sort. In the following example in which a sort is done by salary, the data type is set to number. In a numeric sort, of course, 1,000 follows 2. This sort is also a multiple key sort because two different sort elements are specified. <xsl:stylesheet version=”1.0” xmlns:xsl=”http://www.w3.org/1999/XSL/Transform”> <xsl:template match=”page”> <html> <head><title>Simple Stylesheet</title></head> <body> <h1>Simple Stylesheet</h1> <table border=”0”> <th></th><th>Name</th><th>Job</th><th>Salary</th> <xsl:for-each select=”ROWSET/ROW”> <xsl:sort select=”JOB”/> <xsl:sort select=”SAL” order=”descending” data-type=”number”/> XSLT In-Depth 341 <tr> <td><xsl:value-of select=”@num”/></td> <td><b><xsl:value-of select=”ENAME”/></b></td> <td><xsl:value-of select=”JOB”/></td> <td><xsl:value-of select=”SAL”/></td> </tr> </xsl:for-each> </table> </body> </html> </xsl:template> </xsl:stylesheet> Whitespace Handling You can define how whitespace should be handled for elements by using the xsl:preserve-whitespace and xsl:strip-whitespace elements. The xsl:preserve-whitespace and xsl:strip-whitespace elements are closely related and share essentially the same syntax. Both are top-level elements without chil- dren, and both must be children of the root element. <xsl:preserve-whitespace elements=”element_list” /> <xsl:strip-whitespace elements=”element_list” /> The elements attribute is set to a whitespace-delimited list of element names. For xsl:preserve-whitespace, all whitespace between the start and end tags for those elements is preserved. For the xsl:strip-whitespace, all whitespace between the start and end tags for those elements is deleted. Miscelleneous Elements These last two elements don’t fit in particularly well anywhere else. The first, xsl:key, defines search patterns for elements and is used in conjunction with the key() function discussed later. The second, xsl:message, provides a way to send messages to the XSLT processor, while the third is used with XSLT extensions. xsl:key Syntax The xsl:key element creates identifiers for elements. A key allows you to easily select one or more elements based on the value of an attribute or the value of the element. It is a top-level element that can be a child of the root element only, and it has no children. 342 Chapter 13 Table 13.32 xsl:key Attributes ATTRIBUTE DESCRIPTION Name The name for the key. match The XPath pattern describing a set of elements to match against. use The expression describing an attribute or node of target elements. Used by the key function to evaluate whether or not an element should be included in the return node set. There may be more than one key element per stylesheet, but they should all have unique names. A key is used in conjunction with the key() function. <xsl:key name = “key_name” match = “nodeset_pattern” use = “node_expression” /> Table 13.32 lists the attributes. xsl:message The xsl:message element method provides a mechanism to communicate messages to the XSLT processor. What the XSLT processor does with these messages is processor- dependent. <xsl:message terminate = “yes” | “no”> message </xsl:message> If terminate is set to “yes”, the XSLT processor should stop processing. By default, it is set to “no”. xsl:fallback The xsl:fallback element works with extension elements that aren’t defined in XSLT 1.0. It defines what to do if an extension that you are trying to use is unknown or unavailable to the XSLT processor. <xsl:fallback> Template XSLT </xsl:fallback> The xsl:fallback element should be an immediate child of the extension element that might not be supported. XSLT In-Depth 343 XPath XPath is a language designed to locate nodes in an XML document. The simple paths and expressions that you’ve used thus far are all examples of XPath in action. In many cases, its syntax is similar to that used by file systems. This isn’t coincidental—both XML documents and file systems are tree-based. However, XPath goes a bit beyond the simple path notation you’ve seen so far. It has, for example, its own data types and built-in functions. It also has a rich tool set of axes and predicates; the axes allow you to navigate and grab nodes across the XML tree, and the predicates allow you to filter the nodes that you grab. This section covers XPath by looking first at the different data types that XPath sup- ports. Then you’ll learn formally about expressions and paths, with which, from the previous section, you already have experience. This section concludes with a discus- sion of axes and predicates. The built-in functions are discussed in the final section of this chapter. Expressions and Data Types XPath is a simple language, the key, omnipresent component of which is the expression. An XPath expression is simply some combination of the XPath language elements— operators, paths, variables, predicates, function calls, names, and/or literals. Basically, any time that you write XPath you write an XPath expression. An XPath expression is evaluated to a data type. XPath has four data types: node sets, Booleans, numbers, and strings. They are collectively known as objects. Generally, these types can interchange with one another—for instance, it’s not an error to pass a node set to a string function. It just interprets the string value of the first node as a string. Let’s look at each of these data types in detail. A node set is one or more nodes. An XPath expression such as”ROWSET/ROW/*” returns a node set. Any kind of expression that is meant to return a node set is called a location path. Creating a location path is a lot of the work that you do in XPath, and it is covered specifically in later sections of this chapter. The key to constructing good loca- tion paths is to understand how to use the axes. You may have noticed that there isn’t a data type for just a single node. This is by design: instead of creating a separate data type, XPath keeps it simple by treating sin- gle nodes and sets of node the same. Functions that expect to deal with a single node— string() and number(), for example—simply take the first node in the node set. As a developer, the burden is on you to make sure that the first node is the one that you want processed. The XPath number data type is generally used for pedestrian activities such as counting the number of nodes in a node set. Though not a mathematically strong lan- guage, XPath does give the ability to do the following mathematical operations: ■■ Addition (+) ■■ Subtraction (() 344 Chapter 13 ■■ Multiplication (*) ■■ Division (div) ■■ Modulus (mod) There are several other mathematical functions, covered later in this chapter, that you can use. XPath strings are composed of Unicode characters by default. Since XPath is a text- focused language, a lot of the work that you do deals with strings. The core functions include several string functions that give you a rich set of functionality. With a little work, you can do a lot of parsing and chopping of strings. An XPath boolean value is either true or false, and boolean expressions, covered earlier when you learned about conditional processing, evaluate to either true or false. Location Paths A location path is an expression that returns a node set. Location paths make XPath powerful, but they also make the language complex. A location path describes one or more nodes, where a node is the root node, an element, an attribute, a comment, a namespace declaration, a processing instruction or some text. A location path can be either relative or absolute. It is absolute if it begins with a ‘/’. As with absolute file paths and URLs, an absolute location path starts at the top of the tree. A relative path starts with the context node. Unlike with URLs embedded in Web pages, there is no rule of thumb that says that you should always use relative URLs. In many cases, you should use them, but absolute paths can be invaluable in grabbing data from distant parts of the tree. Any location path is composed of location steps. Location steps can have three parts—an axis, a node test, and a predicate. They take the following form: axis::node-test[predicate] This form probably looks unfamiliar to you, and you may be unconvinced that this was the same language that you were using earlier. A couple of explanations are in order. First, the predicate isn’t required. Second, the child axis is the default axis, which means that a statement such as: ROWSET/ROW translates to: child::ROWSET/child::ROW Following this syntax, ROWSET and ROW are node tests. A node test is a node name, the element wildcard (*), the attribute wildcard (@*), or a node-test function. If a node name is used, only nodes of that name are selected. If the element wildcard character is used, any element will match, while the attribute wildcard will match only attribute nodes. Table 13.33 lists the available node-test functions. XSLT In-Depth 345 Table 13.33 Node-Test Functions FUNCTION DESCRIPTION node() Returns true on any type of node comment() Returns true for comment nodes Processing-instruction() Returns true for processing- instruction nodes Text() Returns true for text nodes Unlike with file systems, the wildcard can be used to skip levels of the tree. The fol- lowing location paths select, regardless of who the parent is, any grandchild of the con- text node named ENAME. */ENAME child::*/child::ENAME The last piece in the puzzle is the predicate. The predicate, which is optional, is a way to filter down the node set achieved by the axis and the node test. Ultimately, it is a boolean expression much like those discussed earlier. If the expression is true, the node will be included in the resultant node set. There is one twist, however. If a num- ber is given in the predicate itself, it will not follow the rules set out earlier. Rather, it will evaluate to true for that particular node in the node set. So the following location path: ROWSET/ROW[3] actually translates to: ROWSET/ROW[position()=3] The position function is invoked on each ROW node, and only the third one will be returned. Axes The XPath class is built around the concept of axes. You can think of an axis as a way to define a relationship between two nodes. For any given two nodes and any given axis, the two nodes are either both on the axis or not. Since XML describes trees, the axes that XPath defines describe tree-based relationships. For instance, one popular axis is the descendant axis of a particular node. Node B is on the descendant axis of node A if it or any of its ancestors is a child of node A. Algorithmically, you can con- sider the descendant axis this way: 346 Chapter 13 Figure 13.4 Descendant axis of a node. 1. Ask node B, “Who is your parent?” 2. Ask the parent, “Who is your parent?” 3. Continue until the answer is “node A” or you reach the root node. 4. If your algorithm stops on node A, node B would be node A’s descendant axis; if your algorithm stops at the root node and the root node is not node A, node B would not be the descendant’s axis. If you are more of a visual thinker than an algorithmic thinker, Figure 13.4 illustrates the same concept. All the nodes denoted with bold circles are on the descendant axis of the node A. This section covers all of the axes in XPath, starting with the most popular. A dia- grams like Figure 13.4 is provided for each axis involving elements. Before moving on, it’s important to make a couple of notes about the diagrams. This particular axis includes the node from which the axis is defined. However, this is not always the case. Thus, the reference element of the axis is delineated with a ring. A square inside the ring means that the reference element is not a member of the axis. Additionally, there are several axes—the sibling axes—that don’t follow the structural connections that XML defines. Thus, the axes are defined with thick dotted lines, whereas the structure is defined with solid lines. self (.) The self axis describes the reference element itself. It has (and always has) one mem- ber only, the reference element. It can be abbreviated with the symbol “.” and is shown in Figure 13.5. XSLT In-Depth 347 Figure 13.5 Self axis. descendant-or-self (//) The descendant-or-self axis includes the reference element and all of its descen- dants. It always has at least one element, the reference element. It can be abbreviated with the”//”symbol and is shown in Figure 13.6. parent ( ) The parent axis includes, at most, one element, the parent of the context element. If the context element is the root element, this axis will be empty; otherwise, the axis will have one member only. It can be abbreviated with the symbol and is shown in Figure 13.7. Figure 13.6 Descendant-or-self axis. 348 Chapter 13 Figure 13.7 Parent axis. attribute (@) The attribute axis includes the attributes of the given element. As discussed earlier, attributes are considered nodes. This is the one XPath axis that works with nonelement nodes. It can be abbreviated with the “@” symbol. child The child axis, which may be empty, includes all the immediate children of the con- text element. It doesn’t include the context element, as shown in Figure 13.8. Figure 13.8 Child axis. XSLT In-Depth 349