Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
<purchase>nodes dated earlier than five days ago. You've heard that XSLT can filter XML documents, so you figure you'll solve this problem in no time. The first task is getting today's date from within a stylesheet, provided that information is not included in the original XML document. Unfortunately, you cannot complete this task with only XSLT. In a situation such as this, you can simplify your XSLT code and solve the problem faster with a Java extension.
Many XSLT processors allow for some type of extension mechanism; the specification requires them to do so. In the world of Java and XML, the most widely used XSLT processor is the open source Apache Xalan processor. Written in Java, Xalan allows for extensions in Java. Many developers find Xalan's extensibility powerful because it lets them utilize their Java skills from within the stylesheet context. Consider the way JSPs (JavaServer Pages), scriptlets, and custom tags add power to HTML. Xalan extensions add power to stylesheets in much the same way: by allowing Java developers access to their favorite tool, Java.
In this article, I will demonstrate how you can use Java from within an XSLT stylesheet. First, we will use Xalan's extensibility
to instantiate and use existing classes within the JDK. Later, I'll show you how to write an XSLT extension function that
String argument and returns a DOM (Document Object Model) fragment to the stylesheet processor.
XSLT is important for J2EE (Java 2 Platform, Enterprise Edition) developers because styling XML documents has become a server-side operation. Also, JAXP (the Java API for XML Processing), which includes support for XSLT engines, has become part of the J2EE specification (J2EE 2.6.11). In its infancy, XSLT was intended to style XML on the client; however, most applications style the XML before sending it to the client. For J2EE developers, this means that the XSLT processor will most likely run within the app server.
Before you continue with this article, be warned that using Java extensions in your XSLT stylesheets will reduce their portability. While extensions are part of the XSLT specification, the way they are implemented is not. If your stylesheets will run on processors other than Xalan, such as Internet Explorer's stylesheet engine, you should avoid using extensions at all costs.
Because XSLT has some weak spots, XSLT extensions prove quite useful. I'm not saying that XSLT is bad; however, it just doesn't offer the best tool for processing everything in an XML document. Consider this section of XML:
<article> <text>XSLT isn't as easy to use as some would have you ... </text> </article>
Suppose your boss asks you to modify a stylesheet so that it converts all instances of "isn't" to "is not" and localizes common labels. Certainly XSLT provides a mechanism to do something along these lines, right? Wrong. XSLT provides no easy way to replace the occurrence of a word or pattern within a string. The same goes for localization. That's not to say it can't be done with standard XSLT syntax. There are ways, but they are not nearly as easy as we would like. If you really want to write text manipulation functions using recursive templates, be my guest.