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

Component Architecture

This explanation covers applications that are based on a single file that contains the end-user application data. In the example in the book, the application is a read-only address book. All the names and addresses are stored in an XML document as a file. There are 500 names contained in about 200Kb in the sample application.

The conceptual details presented here are important for anyone using these components. It doesn't require you to understand any Java. It's really about how the browser requests, documents and XSLT transforms all work together. This is the basic concept of converting the HTTP query parameters into a document that is made available to the XSLT transform engine. The same mechanism is used when the end-user application data comes from a relational database rather than an XML file.

Server Components

The executable implementation is based on:

  • Web application server - Apache Tomcat or Caucho Resin are good for this and they are open sourced.
  • Java servlets - The kernel of the XSLT application server components.
  • XSLT transform engine - The actual libraries that execute the transform. Saxon by Michael Kay and Xalan are good choices.
  • XML source document - Contains the end-user application data in this architecture. In more functional and faster architectures of this same theme, the application data is in relational databases or other XML files.
  • XSLT stylesheet - Single or multiple imported or included stylesheets contains the actual end-user application code. The sample application uses a single stylesheet for simplicity. In any case, multiple XSLT templates are written in these stylesheets.
  • XML configuration file - Allows for multiple instances of the servlet so effectively builds multiple applications in a single servlet engine (Tomcat, Resin, etc.)

Server Process

The fundamental requirement is getting the user inputs, mouse clicks and form entries, into the stylesheet transform execution. Doing this allows you to manipulate the application in response to user inputs strictly by writing XSLT template code.

The way it works is by converting the HTTP query parameters into a document that is then merged with the end-user application data XML document. This is the basic method for the server side XSLT transform to be informed about the user's actions on the browser. By making the HTTP parameters available as an XML document, Xpath expressions can be used to access the form submit results from the browser. For instance, if the browser requested

http://localhost?search=Smith&page=1&debug=on

then the query parameters are the search=Smith&page=1&debug=on part of the whole URL. This amounts to all the knowledge we have about the user's actions when the mouse and keyboard were used on the web browser. Then the servlet code transforms those query parameters into a document that looks like:

<param> 
  <search>Smith</search>
  <page>1</page>
  <debug>on</debug>
</param>

Notice that this 'document' is nothing more than a DOM instance in memory. There is no need for this document to ever have a file to store it in. The result is high speed and freedom from file systems. Also, all these DOM instances and local XML documents only come into existence for the purpose of this application. Don't confuse this use of XML with business to business (B2B) and its pesky problems such as agreed upon schemas for a specific industry. And while we're on the subject of the application of XML, notice that the document fragment below actually has two completely different nodes. One is used to control the application while the other is used to carry the application data.

The next thing the Java servlet does is physically open an XML file that is used for the application data. This file is parsed into a DOM instance and then the document above is inserted into it like this:

<table>
  <param>
    <search>Smith</search>
    <page>1</page>
    <debug>on</debug>
  </param>
  <row>
    <l_name>Smith</l_name>
    <f_name>Bruce</f_name>
    <title>Mr.</title>
    <addr1>4422 Bryan Station Road</addr1>
    <addr2 />
    <city>Lexington</city>
    <state>KY</state>
    <zip>40516</zip>
    <employer>"Addington, Inc."</employer>
    <occupation>Coal Executive</occupation>
    <contrib_id>258</contrib_id>
  </row>
</table>

Finally, this document is sent to the XSL transform and the result returned to the browser as HTML.

Configuration XML

The configuration XML file tells the servlet engine how to associate a particular URL with a specific servlet stored in the file system as a java class file. The schema of this document is not specific to this architecture. It is part of the Java servlet specification from Sun. One very useful feature is the ability to create multiple instances of the same servlet class with each one responding to it's unique URL. That means any number of applications based on this single servlet can run simultaneously in the same web application server. Each one of these would have a separate XML data file and XSLT stylesheet file so they would appear to be completely separate application.

Now if you wanted two simultaneous applications that use the same servlet but serve different end-user applications, here is the complete web.xml document to do that:

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/j2ee/dtds/web-app_2_3.dtd">

<web-app>
<servlet>
<!-- the name reference for the servlet container -->
<servlet-name>xslapp</servlet-name>

<!-- the class name referring to the file xslapp.class -->
<servlet-class>xslapp</servlet-class>

<!-- set the file name for the XSL stylesheet in the web application root directory -->
<init-param>
<param-name>stylesheet</param-name>
<param-value>addressbook.xsl</param-value>
</init-param>

<!-- set the file name for the XML document in the web application root directory -->
<init-param>
<param-name>document</param-name>
<param-value>people.xml</param-value>
</init-param>

<!-- display the raw XML before it gets transformed -->
<init-param>
<param-name>debug</param-name>
<param-value>false</param-value> <!-- set to 'true' to display XML -->
</init-param>
</servlet>

<servlet>
<!-- the name reference for the servlet container (Tomcat) -->
<servlet-name>myapplication</servlet-name>

<!-- the class name referring to the file xslapp.class -->
<servlet-class>xslapp</servlet-class>

<!-- set the file name for the XSL stylesheet -->
<init-param>
<param-name>stylesheet</param-name>
<param-value>mystylesheet.xsl</param-value>
</init-param>

<!-- set the file name for the XML documentl -->
<init-param>
<param-name>document</param-name>
<param-value>mydata.xml</param-value>
</init-param>

<!-- display the raw XML before it gets transformed -->
<init-param>
<param-name>debug</param-name>
<param-value>false</param-value> <!-- set to 'true' to display XML -->
</init-param>
</servlet>

<servlet-mapping>
<servlet-name>xslapp</servlet-name>
<url-pattern>/xslapp</url-pattern>
</servlet-mapping>

<servlet-mapping>
<servlet-name>myapplication</servlet-name>
<url-pattern>/myapp</url-pattern>
</servlet-mapping>
</web-app>

In both the original application and the new application called myapplication, the reference to the class xslapp. However the differences is the name of the XSL and XML files and the URL virtual file requested by the browser which is /myapp for the new application.

Top