Tuesday, 10 June 2008

Java And XSLT By Eric Burke

Just not i completed reading and practicing examples from book Java And XSLT By Eric Burke

Good book to know more about XSLT technology.

Please read Author's Top 10 XSLT tips.

Below are the points i wanted to share with readers from this book.

1) With XSLT, XML data can be transformed into any other text format, including HTML, XHTML, WML, and even unexpected formats such as Java source code.

2) XSLT processors are required to interpret and execute the instructions found in XSLT stylesheets. Many of these processors are written in Java, making Java an excellent choice for applications that must interoperate with XML and XSLT.

3) An XSLT processor,such as Apache's Xalan, performs transformations using one or more XSLT stylesheets , which are also XML documents.

4) HTML does not separate data from presentation.XSLT makes it possible to define clearly the roles of Java, XML, XSLT, and HTML. Java is used for business logic, database queries and updates, and for creating XML data. The XML is responsible for raw data, while XSLT transforms the XML into HTML for viewing by a browser. A key advantage of this approach is the clean separation between the XML data and the HTML views.

5) DOM is specified in the language independent Common Object Request Broker Architecture Interface Definition Language (CORBA IDL), allowing the same interfaces and concepts to be utilized by many different programming languages. Though valuable from a specification perspective, this approach does not take advantage of specific Java language features. JDOM is a Java-only API that can be used to create and modify XML documents in a more natural way. By taking advantage of Java features, JDOM aims to simplify some of the more tedious aspects of DOM programming.

6) Please refer Orielly site for an example implementation of JDOM Implementation infact for downloading all examples.

7) Cell phones, personal digital assistants (PDAs), and other handheld devices seem to be the next big thing. From a marketing perspective, it is not entirely clear how the business model of the Web will translate to the world of wireless. It is also unclear which technologies will be used for this new generation of devices. One currently popular technology is Wireless Application Protocol (WAP), which uses an XML markup language called Wireless Markup Language (WML) to render pages. Other languages have been proposed, such as Compact HTML (CHTML), but perhaps the most promising prospect is XHTML Basic. XHTML Basic is backed by the W3C and is
primarily based on several XHTML modules. Its designers had the luxury of coming after WML,so they could incorporate many WML concepts and build on that experience.

Because of the uncertainties in the wireless arena, an XML and XSLT approach is the safest available today. Encoding your data in XML enables flexibility to support any markup language or protocol on the client, hopefully without rewriting major pieces of Java code. Instead, new XSLT stylesheets are written to support new devices and protocols. An added benefit of XSLT is its ability to support both traditional browser clients and newer wireless clients from the same underlying XML data and Java business logic.

8) The < xsl:value-of select=".">element is similar to printing the name of the current working directory.

9) As the XSLT transformation process continues, the current node and current node list are constantly changing. This is a good thing, since you do not want to constantly search for patterns beginning from the document root element. You are not limited to traversing down the tree,however; you can iterate over portions of the XML data many times or navigate back up through the document tree structure. This gives XSLT a huge advantage over CSS because CSS is limited to displaying the XML in the order in which it appears in the document.

10) Comparing < xsl:template >to < xsl:applytemplates >

One way to understand the difference between < xsl:template>and < xsl:apply-templates>is to think about the difference between a Java method and the code that invokes the method. For example, a method in Java is declared as follows:


public void printMessageBoard(MessageBoard board) {
// print information about the message board
}



In XSLT, the template plays a similar role:

< xsl:template match="messageBoard">


In order to invoke the Java method, use the following Java code:

someObject.printMessageBoard(currentBoard);

And in XSLT, use: < xsl:apply-templates select="..."> to instantiate the template using the current node.While this is a good comparison to help illustrate the difference between < xsl:template> and < xsl:apply-templates>, it is important to remember that the XSLT model is not really a method call. Instead,< xsl:apply-templates> instructs the processor to scan through the
XML document again, looking for nodes that match a pattern. If matching nodes are found, the best matching template is instantiated.

11) Built-in Template Rules

All XSLT processors must include four built-in template rules that have lower precedence than any other rules, so they can be overridden by simply writing a new template rule that matches the same pattern. The best way to think about built-in rules is to assume they are always in the background, ready to be applied if no other rule is found that matches a node.

The first rule allows recursive processing to continue in case an explicit rule does not match the current node or the root node:

< xsl:template match="*/">
< xsl:apply-templates/>


This template matches all elements (*) and the root node (/), i.e., the document itself. It will not match processing instructions, comments, attributes, or text. The < xsl:apply-templates/> causes all children that are not attribute nodes or processing instruction nodes to be processed.

The second built-in rule is identical to the first, except it applies to each mode used in the stylesheet:

< xsl:template match="*/" mode="m">
< xsl:apply-templates mode="m">


Template modes are discussed in the next chapter, so we will not go into details here. The third built-in rule simply copies all text and attribute nodes to the result tree:

< xsl:template match="text( )@*">
< xsl:value-of select=".">


And finally, the built-in rule for processing instructions and comments does nothing. This is why comments and processing instructions in the input XML data do not automatically show up in the result tree:

< xsl:template match="processing-instruction()comment( )">

12) How XSLT Uses XPath

XSLT uses XPath in three basic ways:

· To select and match patterns in the original XML data. Using XPath in this manner is the focus of this chapter. You see this most often in < xsl:template match="pattern"> and < xsl:apply-templates select="node-set-expression">. In either case,XPath syntax is used to locate various types of nodes.

· To support conditional processing. We will see the exact syntax of < xsl:if> and < xsl:choose> in the next chapter, both of which rely on XPath's ability to represent
boolean values of true and false.

· To generate text. A number of string formatting instructions are provided, giving you the ability to concatenate strings, manipulate substrings, and convert from other data types to strings. Again, this will be covered in the next chapter.

13) XSLT provides two mechanisms that support conditional logic: < xsl:if> and < xsl:choose>.These allow a stylesheet to produce different output depending on the results of a boolean expression, which must yield true or false as defined by the XPath specification.

In XSLT, the syntax is as follows:

< xsl:if test="boolean-expression">



14) Unlike most programming languages, < xsl:if>does not have a corresponding else or
otherwise clause. This is only a minor inconvenience because the < xsl:choose>element provides this functionality.

15) One difference between the XSLT approach and a pure Java approach is that XSLT does not require break statements between < xsl:when>elements. In XSLT, the < xsl:when>elements are evaluated in the order in which they appear, and the first one with a test expression resulting in true is evaluated. All others are skipped. If no < xsl:when>elements match, then < xsl:otherwise>, if present, is evaluated.

16) Variables can be defined in one of three ways:

< xsl:variable name="homePage">index.html

< xsl:variable select="president[position() = last()]/name" name="lastPresident">

< xsl:variable name="empty">

To use a variable, refer to the variable name with a $ character.

17) The primary limitation of variables is that they cannot be changed. It is impossible, for example, to use a variable as a counter in an < xsl:for-each>loop.

Another XSLT trick involves combining the variable initialization with < xsl:choose>. Since variables cannot be changed, you cannot first declare a variable and then assign its value later on. The workaround is to place the variable definition as a child of < xsl:variable>, perhaps using < xsl:choose>as follows:

< xsl:variable name="midName">
< xsl:choose>
< xsl:when test="middleName">
< xsl:value-of select="middleName">

< xsl:otherwise>
< xsl:text>




18) The < xsl:include>element allows one stylesheet to include another.

19) Importing (rather than including) a stylesheet adds some intelligence to the process. When conflicts occur, the importing stylesheet takes precedence over any imported stylesheets. Unlike < xsl:include>, < xsl:import>elements must occur before any other element children of < xsl:stylesheet>.Changing all < xsl:import>elements to < xsl:include>will help identify any naming conflicts you did not know about.

About the Author

Eric Burke is an O'Reilly author and a principal software engineer with Object Computing, Inc. in St. Louis, MO. He specializes in Java and his job duties include consulting, training, and public speaking engagements. Eric can be reached at burke_e@yahoo.com.

Hope you enjoy reading this book.

No comments: