ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

JSP vs. XSP
Pages: 1, 2, 3

A Minimal XSP Page

An XSP page is an XML page with the following requirements.



  • It must have a cocoon processing instruction that invokes the XSP processor <?cocoon-process type="xsp"?>
  • The document root element must be <xsp:page>
  • It must also have any language and Taglib declarations as attributes in the <xsp:page> tag (e.g. <xsp:page language="java" xmlns:xsp="http://www.apache.org/1999/XSP/Core">)
  • In order for the XSP page to be useful, it will usually require at least an <xsp:logic> element and an <xsp:exp> element.

Usually you will also require further processing of the resulting page -- perhaps with a stylesheet -- to transform the resulting code into a readable form for the viewer.

Cocoon processing instructions act upon a whole document, which generates a result document, which will in turn be passed to the next Cocoon processor, rather like a pipeline. This is similar to Servlet chaining.

What follows is a minimal XSP page that shows a simple page counter. (Note that the <-- lines are comments):

<-- required for every XML page-->
<?xml version="1.0"?>
<-- first process this page with the Cocoon XSP Processor -->
<?cocoon-process type="xsp"?>
<-- then run the results through the XSLT processor -->
<?cocoon-process type="xslt"?>
<-- Tell the XSLT processor which stylesheet to use -->
<?xml-stylesheet href="page-html.xsl" type="text/xsl"?>
<-- This is required for an XSP page -->
<xsp:page language="java" xmlns:xsp="http://www.apache.org/1999/XSP/Core">
<-- <xsp:logic> tags specify definitions of things in the language that is used on this XSP page -->
<-- usually functions and class-wide variables. -->
<xsp:logic>
static private int counter = 0;

private synchronized int count() {
return counter++;
}
</xsp:logic>

<--
This is the bulk of the page content specified as general XML. The first element that you place here (in this case <page>) will become the document root element of the XML document that will be generated after the XSP processor has finished. The <xsp:expr>count()</xsp:expr> element here is saying "call count() and convert the result into a text node". <xsp:expr> is used wherever you need to insert live data into the output document.
-->

<page>
<p>This page has been requested <xsp:expr>count()</xsp:expr> times.</p>
</page>
</xsp:page>

The output of the XSP processor will produce the following page the first time the page is requested.

<?xml version="1.0"?>
<?cocoon-process type="xslt"?>
<?xml-stylesheet href="page-html.xsl" type="text/xsl"?>
<page>
<p>I've been requested 0 times.</p>
</page>

A Minimal JSP Page

A minimal JSP page is nothing more than an HTML page. Although not very interesting in terms of any dynamic content, it can be compiled in the Servlet engine.

Different Types of Pages

There are typically three types of pages that can be developed with either JSP or XSP technology.

The first and, admittedly, the worst uses embedded logic. In this case, code is placed directly into the XML or JSP. This defeats the purpose of separation of tasks. It also makes the page prone to updates and changes. For any production quality project, this is definitely not the development option you want to employ, unless you want to be looking for a new job soon.

The second, preferable way matches parts of the original document, either by a stylesheet in the XSP case or template in the JSP case, and replaces those parts with sections of logic code. In the XSP scenario, an XSP page is generated from the original XML page, rather than the original XML page being an XSP page. The result of this transformation is a canonical XSP page. This will then be "executed" and the result will be an XML page with all the variable pieces replaced with actual values. Once again, the XSL stylesheet transforms the final outcome into a HTML page.

The third case could be dealing with either of the two previous scenarios, the only difference being where the tab library exists. The taglibs are central libraries that can be referred to anywhere within an XSP page. The most important aspect of the taglib is that it has an XML URI namespace declaration which is declared in the original logic sheet and matched in the <xsp:page> xmlns attribute in the XSP case. The Cocoon properties file also needs to know where to find the XSL file.

For a JSP, the tab library is defined in the directive

<%@ taglib uri="/myTldExample.tld" prefix="example" %>

A sample XSP page might look like

...
<xsp:page xmlns:example="http://www.oreilly.com/xspExample">
...
</xsp:page>

The logic sheet file might look like

<xsl:stylesheet version="1.0"
xmlns:example="http://www.oreilly.com/xspExample">
...
</xsl:stylesheet>

And finally the cocoon.properties would have the following entry:

processor.xsp.logicsheet.example.java = file:///oreilly/xspExample.xsl

A Few Small Differences

If you are developing in either technology there are probably a few small differences that you will notice.

  • XSP automatically generates import statements for the most commonly used Java packages. JSP has to have explicit imports. The packages that get included for XSP are

    • java.io.*;
    • java.util.*;
    • org.w3c.dom.*;
    • org.xml.sax.*;
    • javax.servlet.*;
    • javax.servlet.http.*;
    • org.apache.cocoon.parser.*;
    • org.apache.cocoon.producer.*;
    • org.apache.cocoon.framework.*;
    • org.apache.cocoon.processor.xsp.*;
  • XSP allows the <xsp:logic> element to be arbitrary nested without the need to prematurely close it.

    <table>
    <xsp:logic>
    for (int i = 0; i &lt; items.length; i++) {
    <tr>
    <td>
    <xsp:expr>items[i].getName()</xsp:expr>
    </td>
    </tr>
    }
    </xsp:logic>
    </table>

    This lends itself to simpler code than having to push Nodes.

    • It is unnecessary to cast variables explicitly to String when using XSP. <xsp:expr> takes care of converting all Java types so that values are properly converted depending on context.
    • It is impermissible to nest <xsp:expr> tags directly inside <xsp:logic>. For an expression to be inlined inside an <xsp:logic> element, it must be escaped by surrounding it with an <xsp:content> tag. For example,

      <xsp:logic>
      for (int i = 0; i &lt; someArray.length; i++) {
      <xsp:content>
      <xsp:expr>someArray[i]</xsp:expr>
      </xsp:content>
      <br/>
      }
      </xsp:logic>

    • The < and & characters are special to XML parsers. When using them in files they must occur &lt; and &amp;. A workaround is to escape code chunks containing these characters as CDATA sections, like

      <table>
      <xsp:logic><![CDATA[
      for (int i = 0; i < someArray.length; i++)]]>
      <tr>
      . . .
      </tr>
      }
      </table>
      </xsp:logic>

      Just make sure you avoid enclosing static markup inside the <![CDATA]]> section, as this will result in syntax errors by the producer.

Pages: 1, 2, 3

Next Pagearrow