XslRoot Project
Home
Help and Download
Mail list help and software download from SourceForge
Why use XSLT
Rationale for using XSLT to build web applications.
Architecture
Component Architecture and Sample Application
Case Study Support
Support for users of Beginning XML 2nd Edition Case Study One published by Wrox Press.
Sample App Display

Database Applications
Sample database application built in XSLT, XML and SQL. No Java is required to modify this sample application to your own purposes.
Database Architecture

Advantages of Using XSL to Build Interactive Web Applications

The best single reason for using XSL for web applications is that its easy. It's easy to lay out a web page. It's easy to incorporate end-user application data. It's easy to make complex user interface behavior.

It's easy because XSL handles all the conditional processing that is usually done in Java or Visual Basic or Perl code. It's easy because XSL handles all the data access and filtering usually done by SQL scripts or database connections or special parsing of text files. It's easy because XSL is the same thing as HTML is so the page presentation layout is echoed in the node layout of the XSL templates. It's easy because XSL is the same thing as the XML source data so it can manipulate and display the data in one uniform syntax and structure using Xpath expressions. It works with completely standard XML and XSL files without special extensions. There is no compiling so changes you make to the XSL stylesheet are seen immediately.

The Project/People/Architecture Problem

In many projects the HTML page designers have their hands tied because a great deal of the HTML and the business rules logic is buried in the Java or Visual Basic code. Yet it is exactly these page design people that end up with the task of maintaining web applications. But web page designers are not hard core procedural language programmers.

Management doesn't want to pay for high priced Java gurus to change the look or content of an application. However, there is no way of avoiding this problem because JSP must rely on Java and ASP must rely on VB for conditional processing. So there is a mix of languages and functions written in Javabeans, pages and COM objects in JSP and ASP applications. There is no hope that page designers will be able to maintain web applications that are built this way.

What would be useful is a language that is accessable to page designers but also has the user interaction logic and the data access built right in. I know this sounds like breaking the separation of display layout, business logic and data access that have become the mantra of three tiered architecture. However, these different tiers can remain loosely coupled using properly designed XSLT templates. Also, at the point of the user interface coding, somehow all three functions: layout, behavior and data must come together to present a single, consistent application to the user.

XSL is an Easy Web Building Solution

Just how easy is XSL? Here are a few code fragments that compare JSP and Java with XSL to validate a user entry. Using JSP:

<!-- this comment is in the HTML and JSP area -->
<%
// start of Java
String strLastName = request.getParameter("l_name");
if(strLastName.equals("")) {
// end of Java
%>
<!-- more HTML -->
You must enter at least one character.
<% // Java continues to close the code block
}%>
<!-- HTML and JSP continues -->

But doing the same thing in XSLT looks like:

<!-- test for user input string-length less than 1 -->
<xsl:if test="string-length($param/search) &lt; 1 and $param/search">
  <!-- if so, insert this HTML -->
  <font color="red">
    At least one character required!
  </font>
</xsl:if>

These simple examples shows how JSP must use two languages and weave them right into each other while XSLT is a single language but can do layout and conditional processing.

XSLT Language Concept

Since XSL and HTML are both rooted in XML, they are syntactically and structurally the same thing. That means if you think of HTML in terms of nodes, tags and attributes, you will find XSL to be identical. Also, the source data to be presented in the resulting HTML page is itself XML which is, again, the exact same structure as the language we are using.

If, on the other hand, you see HTML as really just a long string of characters punctuated with pointy brackets, XSL will be a disappointment. But there isn't much choice about that when you use procedural languages. In Java, for instance, the tags are treated as text strings which are concatenated with the application data which is also treated as a text string:

out.write("<tr><td>Last Name</td><td>" + resultSet.getString("lastname") + "</td></tr>");

However, this way of thinking of HTML is not the way HTML web page designers think about HTML. They think in terms of tags and how they will effect the page appearance. Here is the same example using XSL:

<tr>
  <td>
    Last Name
  </td>
  <td>
    <xsl:value-of select="lastname"/>
  </td>
</tr>

XSLT as a Standard

There are numerous XSLT transform engines available today that will run in the Java, Visual Basic and Perl execution environments. Both Microsoft and Sun have provided XSL transform engines free. XSL is specified by the W3C consortium through a consensus process with many of the largest software vendors. In contrast, there are a number of proprietary tag and script languages that do provide the integration of data, presentation and business rules but each one of them is very different. Examples are Allaire's Jrun and ATG's Dynamo application servers. For instance, they both include an 'if' function in their proprietary tag language but they don't share the same syntax or structure.

Top