Techniques in my new book, Java and XSLT, describe the technical mix of Java and XSLT. This article picks up 10 tips that I think are very important in the book. But actually this limited 10 is just a rough description of what is possible. Most of these are concentrated in the combination of Java and XSLT, rather than in XSLT (Extensible Stylesheet Conversion) technical specifications. And more detailed information, at the end of the article pointed out some valuable resources.
The basic XSL transformation is very simple: one or more XSLT stylesheets containing instructions that define how to convert XML data into other formats. The XSLT processor does the actual work; Sun Microsystems Java API for XML processing (JAXP) provides a standard set of Java interfaces for different kinds of processors. Here's a simple example of using the JAXP API to perform XSL transformations:
Import Javax.xml.transform.Source;
Import Javax.xml.transform.Transformer;
Import Javax.xml.transform.TransformerFactory;
Import Javax.xml.transform.stream.StreamSource;
Import Javax.xml.transform.stream.StreamResult;
Import java.io.*;
public class Transform {
/**
* Performs an XSLT transformation, sending the results
* to System.out.
*/
public static void Main (string[] args) throws Exception {
if (args.length!= 2) {
System.err.println ("Usage:java Transform [xmlfile] [xsltfile]");
System.exit (1);
}
File XmlFile = new file (Args[0]);
File XSLTFile = new file (args[1]); JAXP reads data using the Source interface
Source Xmlsource = new Streamsource (xmlFile);
Source Xsltsource = new Streamsource (xsltfile);
The factory pattern supports different XSLT processors
Transformerfactory transfact = Transformerfactory.newinstance ();
Transformer trans = Transfact.newtransformer (Xsltsource);
Trans.transform (Xmlsource, New Streamresult (System.out));
}
}
You can click here to download a small zip file that contains this example and the corresponding XSLT stylesheet and XML data file. The Readme file explains how to compile and run this example.
This example uses Streamsource to read data from a file, and JAXP can read XML data from a SAX interpreter or a DOM tree. Here are the 10 tips I recommend:
1, use the cache whenever possible.
Performing XSLT transformations is very CPU-and memory-intensive, so it makes sense to make possible optimizations at any time. One of the best ways to improve the performance of a Web application that is driven by XSLT is to use various types of caching techniques.
Figure one illustrates a typical Web application that uses XSL to transform a database.
Figure one, typical XSL transformations
Unlike dynamically generated XML, XSLT style sheets are statically stored in a file. Since these files are rarely altered, they can be parsed into memory by using JAXP's Javax.xml.transform.Templates interface. The following piece of the program explains how the process is done:
Source Xsltsource = new Streamsource (xsltfile);
Transformerfactory transfact = Transformerfactory.newinstance ();
Templates cachedxslt = transfact.newtemplates (Xsltsource);
Transformer trans = Cachedxslt.newtransformer ();
When the XSLT stylesheet is cached in memory through the templates interface, it can now be reused for many different transformations. The most important benefit is that this avoids the repetition of parsing the XSLT into memory. It also gives the XSLT processor an opportunity to optimize the conversion instructions, just as the compiler optimizes the software.
One might wonder if the XML data can also be cached in memory. For highly dynamic and individualized applications, XML data is dynamically generated with each client request and is changing at any time. For this application, caching is impractical. For many other types of applications, XML data may not change very frequently. When the data changes are not very frequent, the converted result cache may be more meaningful relative to the cached XML data. This is one of the fastest possible solutions and is recommended to be used wherever practicable.
2, test before deployment.
The key to choosing XML and XSLT in developing Web application projects is that you can clearly separate data, program logic, and presentation. Java code interacts with the background data source and generates XML data, and the XSLT stylesheet converts the XML data to XHTML (or WML, or other), and the browser displays the results.
A unique, but often overlooked, advantage of this structure is its ability to support automated unit testing. Tools such as JUnit encourage programmers to write kits for automated unit testing. These tests greatly reduce the errors that occur when adding new features to the system. Consider these components of a typical JAVA+XML+XSLT Web site:
Implement business logic in Java. Because the Java code does not mix with the expression logic, it can be tested like any other Java code.
Convert the application data to XML. This step is particularly easy. Just generate the XML and then validate it with a DTD or an XML schema.
Converts XML to XHTML. Similarly, the generated XHTML can be validated with an XHTML DTD. While this does not prove that the information is correct, it does ensure that XHTML is correctly generated and valid.
Unlike many other web development technologies, testing any of these units does not have to be deployed to a Web server. This makes automated unit testing easier to implement, and automated unit testing is also a key component of extreme Programming (XP) technology.
3, try to make XSLT style sheet simple.
There are at least two reasons to keep your XSLT stylesheet simple. First, XSLT is not a programming language as rich as java. Although XSLT is a good translator, embedding too many application logic into a stylesheet can make it quite complex. For this reason, you should use Java to implement as much business logic as possible before creating the XML. Then it should be much simpler to transform XML with XSLT.
The second reason to keep the stylesheet simple is that XSLT's syntax is not easy to read. XML tags make XSLT easy to parse and facilitate programmatic processing, but all of those XML tags make stylesheets difficult to read. There are a few tips to help programmers understand and work with XSLT stylesheets more easily:
Use an editor with syntax-sensitive features, such as Altova XML Spy.
Add a different annotation for each XSLT template. This helps to break the monotony of searching in large stacks of ' < ' and ' > ' Strings.
Use a certain naming convention for variables and style sheet parameters at the highest level.
Take the common method out and put it in the second stylesheet, and use <xsl:import> to reuse the code.
4. Use CSS with XSLT.
This technique is associated with the previous one, and it can greatly reduce the complexity of the XSLT style sheet.
XSLT and CSS perform different tasks separately and complement each other. XSLT converts XML into other formats, such as XHTML or WML, while CSS simply defines the style of expression. As part of the generated XHTML, sometimes XSLT can also generate some style elements to blur the lines.
It is recommended that you write separate CSS files instead of embedding a lot of font, color, and other style elements in the XSLT style sheet. The XHTML generated by the XSL transformation only contains these standalone CSS files. This makes XHTML smaller, simplifies XSLT, and allows browsers to download pages more quickly.
The same technique applies to JavaScript, which should be stored in separate files instead of embedding them directly into the transformation.
5, careful processing of uninterrupted space.
Author Tip: As a response to the reader, I've rewritten this technique to add new knowledge about nonbreaking spaces that I've learned recently. Thanks to the feedback of the general readers. [Editor's note: We have added a reader feedback link to the tail of the file for additional comments.] ]
nonbreaking spaces are a useful feature of XHTML, which prevents browsers from introducing line breaks in text. It also makes it possible to force more than two consecutive spaces, because browsers always process ordinary spaces (and other white space characters) into a single space. Here is an example of XHTML that contains nonbreaking spaces:
Aidan Burke
When people create XHTML pages, they usually insert "" characters into their source files as shown above. All browsers will translate this sequence of characters into a nonbreaking space and display it correctly. However, when you generate XHTML with XSLT, the method of processing is different.
The XSLT style sheet must be well-formed XML. Because "" is not an XML predefined five tag, it cannot be included directly in the stylesheet. For example, the next XSLT slice doesn't work:
<!--won ' t work ...-->
<xsl:text>aidan burke</xsl:text>
This feature makes it necessary for XSLT programmers to use this feature in a slightly different way:
<xsl:text>aidan burke</xsl:text>
The results show that all the cases are working well. A processor like Xalan automatically converts character entity "to sequence" when the stylesheet's output method is "HTML". From a Web browser's point of view, this looks like any other nonbreaking space.
Here's an example of a complete XSLT stylesheet that does this
<?xml version= "1.0" encoding= "UTF-8"?>
<xsl:stylesheet version= "1.0"
Xmlns:xsl= "Http://www.w3.org/1999/XSL/Transform" >
<xsl:output method= "html" encoding= "UTF-8"/>
<xsl:template match= "/" >
<xsl:text>aidan burke</xsl:text>
</xsl:template>
</xsl:stylesheet>
When Xalan is used, the output of this transformation looks like this:
Aidan Burke
This is good because the browser knows how to display "". Unfortunately, the XSLT specification does not require the XSLT processor to convert "" to "". You must perform this test on the XSLT processor you use at any time you encounter this problem.
Some programmers do not like to have to remember "160" to represent nonbreaking spaces. So they define such an entity in the DTD sub set of the XSLT style sheet:
<?xml version= "1.0" encoding= "UTF-8"?>
<! DOCTYPE Xsl:stylesheet [
<! ENTITY nbsp "" >
]>
<xsl:stylesheet version= "1.0" ...
Now, you can use "" instead of "". This facilitates the author of the stylesheet because the XML parser converts the entity to "" before XSLT Processes "". Note: Some XML-related tools try to validate XSLT stylesheets when they see DOCTYPE. Because the DTD subset does not contain the definition of all XSLT elements, validation reports an error.
What is the problem if the popular XSLT processor automatically converts "to"? The problem is that an error occurs when the stylesheet's output is "xml" rather than "HTML."
When the XSLT output method is "HTML", most XSLT processors modify their output and provide it to the Web browser. For example, a label like "<br/>" is a valid XML that may be converted to "<br>". This is more useful in older browsers, but not in well-formed XML.
XHTML is the format currently recommended by the Internet Consortium for writing web pages. Because XHTML documents must be well-formed XML,XSLT style sheet authors are likely to want to use the output format of "XML" instead of "HTML" when generating XHTML. This is the first part of an XSLT style sheet that generates XHTML:
<?xml version= "1.0" encoding= "UTF-8"?>br>
<xsl:stylesheet version= "1.0"
Xmlns:xsl= "Http://www.w3.org/1999/XSL/Transform" >
<xsl:output method= "xml"
doctype-public= "-//W3C//DTD XHTML 1.0 strict//en"
Doctype-system= "Http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
encoding= "UTF-8"/>
<xsl:template match= "/" >
... remainder omitted
When the output method is "XML", Xalan does not convert "" to "". Instead, it inserts a 160 character code in the result tree. This can cause problems in some cases. For example, Figure 2 is a screenshot of the IE 5.5 browser running on Windows 2000. Notice that there is a symbol on the interesting letter "a":
Download this example to try the results.
The lower half of Figure 2 shows a switching technique that works in most cases. The following describes how it works:
<xsl:text disable-output-escaping= "Yes" > </xsl:text>
Disable-output-escaping= "Yes" causes the XSLT processor to no longer convert "" to character code 160 when generating the result tree. Instead, it retains the character sequence "" without changing it. This allows the browser to display the nonbreaking spaces correctly.
I must remind you that the XSLT specification does not require an XSLT processor to support disable-output-escaping, so anyone who uses this technique should test it with a special tool.
Figure 2, using the "XML" Output method (above) and the results by using the Disable-output-escaping method (bottom) to compare
Here's a summary of the techniques mentioned above:
Use the character entity to represent the nonbreaking space. Because most XSLT converts this entity to a character sequence "", this can work correctly when the output method is "HTML". The XSLT specification did not require this, but Xalan did so.
Define a "" entity and use it. This is as efficient as the previous one, but it looks a little better for the style sheet author. However, some tools may try to validate the stylesheet with a nonexistent DTD, which can cause problems.
Use the <xsl:text disable-output-escaping= "yes" > </xsl:text> as "" as the second choice. This is especially useful when the output method is "XML." The XSLT specification does not require the processor to support disable-output-escaping.
6, write XML Generator class.
In order to apply an XSL transformation, you must convert the Java object to a certain amount of XML data. This can be done in several ways:
1 Add a Getxml () method for each class.
2 Write an XML builder that knows how to convert a particular object to XML.
3 Convert to XML using a well-known Java-to-xml API.
The first approach might look something like the following:
public class Customer {
Public Element GetXML (Document doc) {
Use the DOM API to create a Element
Representing this object
...
}
...
}
This approach is easy to interpret and understand, but it has a key design disadvantage. The key problem is that specific XML representations are tightly tied to each class. When a new XML representation is required, a new method must be written. This means that when more and more XML "views" are added, the class becomes larger.
It's not hard to imagine a situation where you want more than one XML representation for an object. Only a few key fields per customer appear in the XML data in one of the hundreds of customer profile reports. In a customer's detailed report, the XML data should contain all the information about the customer.
The second way is to separate the generated code of the XML into several tool classes. A customer-related XML generator might look something like the following:
public class Customerdomproducer {
public static Element ToXML (Customer Cust, Document Doc) {
... use the DOM API to create a fragment of XML
}
}
Simply remove the XML generated code from the customer class and simply write the additional Xxxdomproducer class when adding new XML expressions. This could even be replaced with non-dom APIs like Jdom, and no change to the customer code.
--------------------------------------------------------------------------------------------------------------- --------
For more information on Jdom, don't miss Brett McLaughlin's recently released "Java&xml, 2ndEdition."
--------------------------------------------------------------------------------------------------------------- --------
The third approach is also worth mentioning, which is to convert Java objects into XML using a product. Although these types of tools are good for ongoing and data exchange with applications, they may not be ideal for XSL transformations. This is because the generated XML may be much more complex than the handwritten code scheme provides, potentially leading to a more complex XSLT style sheet.
7. Suppose the cookie is prohibited.
The Servlet API supports the use of HttpSession to track sessions. This makes possible a technology like a shopping cart. The default behavior of this class is to rely on the browser's cookie to authenticate each user, but the user can disallow cookies.
When the browser cookie is banned, our application must rely on some other mechanism to authenticate the user. URL rewriting is the technique used by the servlet API. URL rewriting does not occur automatically for a variety of reasons. To support session tracking when a cookie is blocked, the programmer must remember to encode every URL issued by the application. This can be done by adding a jsessionid=nnnnn for each hyperlink, form action, or redirect URL. The following table lists URLs with and without validation tags:
URL encoded by normal URL
<a href= "MyLink" > <a href= "mylink;jsessionid=129j2fjs87l156" >
<form action= "MyLink" > <form action= "mylink;jsessionid=129j2fjs871156" >
When a user clicks on a coded hyperlink or submits an encoded form, the servlet container can determine his or her identity by checking the value of the Jsessionid.
When generating XHTML with XSLT, because the authentication identity is dynamic and each user's identity is different, the session identity should be embedded in each page and should be passed as a parameter of a stylesheet. Here is an example of how to define this parameter at the top of each XSLT style sheet:
<xsl:stylesheet version= "1.0"
Xmlns:xsl= "Http://www.w3.org/1999/XSL/Transform" >
<!--
*********************************************************
* * global.sessionID:Used for url-rewriting to implement
* * Session tracking without cookies.
*********************************************************
-->
<xsl:param name= "Global.sessionid"/>
...
In a servlet-side application, Java code passes this session identity to the XSLT processor using the JAXP transformer class. It's smart enough to do this only if the cookie doesn't work:
protected void Doget (HttpServletRequest req, httpservletresponse Res)
Throws IOException, Servletexception {
Transformer trans = ...//obtain Transformer from JAXP
HttpSession session = Req.getsession (true);
Allow cookieless session tracking
if (!req.isrequestedsessionidfromcookie ()) {
String SessionID = Session.getid ();
Trans.setparameter ("Global.sessionid", "; jsessionid=" + SessionID);
}
Back in an XSLT-side application, this Global.sessionid parameter can be added to hyperlinks and form actions when each page is generated. This technique is fully explained in the 8th chapter of "Additional techniques" in the Java and XSLT.
8. Use XSLT as a code generator.
Although XSLT is often used to make web-based transformations, it is not limited to output as XHTML. XSLT can convert XML to any text format, which makes it an ideal choice for many types of code generators and other development tools.
When using XSLT as a basic code generator, it is best to focus on repetitive and highly structured applications. Many EJB-related applications are highly structured and somewhat repetitive, making XSLT an ideal choice for code generation.
--------------------------------------------------------------------------------------------------------------- ----------
Look forward to O ' Reilly's "Enterprise Java Beans" Third edition, since September will be released.
--------------------------------------------------------------------------------------------------------------- ----------
9, for i18n <xsl:import>
Figure 3 shows how to modularize XSLT style sheets to support internationalization:
Figure 3, XSLT internationalization
This is an interesting trick to take advantage of <xsl:import> features. With <xsl:import>, a style sheet can import one or more other style sheets. If the stylesheet "a" imports style sheet "B", the modules and variables defined in the stylesheet "a" take precedence over those found in style sheet "B".
The style sheet for a particular language might look like this:
<?xml version= "1.0" encoding= "UTF-8"?>
<xsl:stylesheet version= "1.0"
Xmlns:xsl= "Http://www.w3.org/1999/XSL/Transform" >
<xsl:import href= "Common.xslt"/>
<xsl:variable name= "Lang.pagetitle" >welcome to Xslt!</xsl:variable>
</xsl:stylesheet>
This may be the case for a common style sheet:
<?xml version= "1.0" encoding= "UTF-8"?>
<xsl:stylesheet version= "1.0"
Xmlns:xsl= "Http://www.w3.org/1999/XSL/Transform" >
<xsl:output method= "html" encoding= "UTF-8"/>
<xsl:template match= "/" >
<title><xsl:value-of select= "$lang. PageTitle"/></title>
... etc
As shown here, the common style table does not write to the specific text that the user displays (such as the page title). Instead, it relies on variables defined in a language-specific style sheet. In this way, adding new language support is just a style sheet for creating a new language.
This is very similar to "ordinary Java" internationalization, which is the language-related text that is defined by different attribute files.
10, set up Streamsource to resolve the relevant URI.
Take a look at the following JAXP code (highlighted in the problematic section):
Stream containing XML data
InputStream Xmlstream = ...
Stream containing XSLT stylesheet
InputStream Xsltstream = ...
Source Xmlsource = new Streamsource (xmlstream);
Source Xsltsource = new Streamsource (xsltstream);
Transformerfactory transfact =
Transformerfactory.newinstance ();
Transformer trans = Transfact.newtransformer (Xsltsource);
Trans.transform (Xmlsource, New Streamresult (System.out));
Now suppose this XSLT stylesheet imports another stylesheet, as follows:
<xsl:import href= "Formatname.xslt"/>
It can cause problems when the XSLT processor doesn't know where to find FORMATNAME.XSLT. The same problem can occur when you include references to other files in your XML data. This code can be resolved by changing the structure of the Streamsource object:
Source Xmlsource = new Streamsource (Xmlstream, "file:///C:/data/xml/");
Source Xsltsource = new Streamsource (Xsltstream, "file:///C:/data/xslt/");
The second parameter provides a URI that contains XML and an XSLT file. Now, when the XSLT processor parses the URI references in the XML data and XSLT style sheets, it knows where to look for them.
More knowledge
XSLT is not a very difficult language, although it works in a very different way than Java. Burying your style sheet is probably the best way to overcome your beginner's difficulties. Here are some additional resources for XSLT:
Javaxslt_example.zip: Download An example of an XSLT stylesheet, an XML file, and a simple JAXP conversion program.
The latest XSLT specification the latest XSLT specification for the Internet Alliance.
Sun ' s Java API for XML processing (JAXP) site: Provides a standard set of Java interfaces for different kinds of XML parsers and XSLT processors
Altova ' s XML Spy: An XML editor that supports XSL transformations.
The SAXON XSLT processor: An XSLT processor from Michael Kay.
The Xalan XSLT processor: An XSLT processor from the Apache organization.
