D
delphiasp
Unregistered / Unconfirmed
GUEST, unregistred user!
JSP vs. XSP
02/22/2001
Overview
In the world of server page acronyms, XSP is gaining recognition.
It's the next evolution of server pages.
Sue Spielman will be speaking about XSP at the O'Reilly Conference on
Enterprise Java, March 26-29, in Santa Clara, California.
XSP stands for eXtensible Server Pages and is one of the core technologies
available in Cocoon. Cocoon is one of the seven current parts of the Apache
XML project. The new Cocoon paradigm is based on the fact thatdo
cument
content, style, and logic are often created by different individuals or
working groups. Cocoon aims for a complete separation of the three layers.
In other words, Cocoon allows content, logic, and style to be separated into
different XML files, and it uses XSL transformation capabilities to merge them.
While having similar concepts to Java Server Pages (JSP), there are a number
of differences present in XSP. We will look at both technologies to see how
they stack up against each other. This article assumes you have at least some
understanding of XML and its terminology.
XSP Technology
The main concept behind a web site using XML is the separation of content,
logic, and presentation. XSP provides the front-end portion of an XML
framework. Providing dynamic XML pages that are parsed and transformed by the
framework allows application interoperability, yet the pages are constructed
and stored as static files on a file system.
Just as Java is aimed at providing a clear separation of content from
application and business logic, XSP seeks to provide the same for XML-based
applications. Although many of the currently available XML frameworks allow
this separation of layers within compiled code, changes to the formatting of
actual data in an XMLdo
cument still require Java code and subsequent
recompilation.
XML browsers are useless without some predefined semantics. This is one of
the reasons why XSL (the eXtensible Stylesheet Language) was proposed and
designed. XSL is divided into two parts: transformation (XSLT) and formatting
objects (variously referred to as FO, XSL:FO, or simply XSL). Both are XML
DTDs that define a particular XML syntax: every XSL or XSLTdo
cument is a
well-formed XMLdo
cument.
The Cocoon publishing model is heavily based on XSLT's transformation
capabilities. XSLT allows complete separation of content and style, something
everyone writing web applications has been striving toward but has been
unsuccessful at. This separation is much harder to obtain with HTML, even if
CSS2 or other styling technologies are being used. But Cocoon goes further and
defines a way of separating content and style from the programming logic that
drives server-side behavior. The XSP language defines an XML DTD for separating
content and logic for compiled server pages.
In dynamic content generation technology, content and logic are combined.
There is typically a mix of static content and dynamic logic that work
together to create the final result, usually using run-time or time-dependent
input. XSP is no exception. It defines syntax to mix static content and
programmatic logic in a way that is independent of both the programming
language used and the binary results that the final source rendering generate.
It should be understood that XSP is just a piece of the framework. In much the
same way that formatting objects mix style and content, XSP objects mix logic
and content. On the other hand, since both are XML DTDs, XSLT can be used to
move from pure content to these final DTDs, placing the style and logic in the
transformation layers and guaranteeing complete separation and easier
maintenance.
JSP Technology
The intention of JSP technology was to provide a clean separation between
content and presentation. While making great strides indo
ing so, it falls
somewhat short. While JSP has simplified many of the server-side Java
programming details, it still can't quite make the clean break it was intended
to. If you have delivered a large-scale application using JSP you will no
do
ubt agree.
JSP mingles content (pure data) with presentation in the same way static HTML
does. JSP allows tags and inline Java code to be inserted into an otherwise
normal HTML page. When the JSP page is requested, the resulting code is
executed in a Servlet engine and the results are inserted right into the output
HTML. JSPs tend to be specific for an application because they are designed
from the outset for the delivery of output from that application. A typical
JSP pages contains static HTML/XML components, JSP tags, and optional snippets
of Java code called scriptlets. You can create and maintain JSP pages with your
favorite HTML/XML tool.
By using XML-like tags, scripting elements, scriptlets, and directives, a
content developer can accomplish quite a lot. Scripting elements and
expressions allow for runtime evaluation of variables. Directives can be
used to control certain aspects of the actual workhorse servlet's operation.
To simplify the scripting elements, a JSP developer has access to a number of
predefined variables such as request, response, in, and out. These variables
represent, respectively, HttPServletRequest, HttpServeletReponse, PrintWriter,
and BufferedReader. There are a few other predefined variables but for this
discussion those listed should suffice. Scriptlets provide a mechanism to
insert code into the servlet's service method. In addition, JSP can work
hand-in-hand with JavaBeans. By embedding beans within a JSP, it is possible
to encapsulate functionality for a JSP as well as reuse the bean in other
development efforts. Special treatment is given to beans in a JSP, which can
make for a cleaner, less cluttered JSP page. For example, parameter values
in a client request can automatically be used to set a bean's properties. Beans
also have scope and can be used per request, between pages, or even throughout
an application.
Custom Tag libraries also provide a way for JSP to separate content from
presentation. Using custom tag libraries it is possible to create business
logic that is almost completely hidden from the presentation developer. The
only thing that the presentation developer has to know is how to reference
the tag library and use the tag. This could be as simple as one line of code,
or it could be more complicated if tag interaction is required.
As you can see, JSP technology is very powerful and useful but is not ideal.
The Object Models
The XSP model works on the concept of processor and producers. A processor is
a Cocoon Java type that takes ado
M tree as input and produces another
(possibly modified)do
M tree as output. Think of it as a filter in a command
pipeline. The XSP engine is implemented as a Cocoon processor that accepts an
XSP page as input. The first time a given XSP page is processed, it is
translated into an equivalent source program that is then
compiled, loaded,
and executed. Subsequent requests for the same XSP page result in the execution
of the generated program. As you may expect, the outputdo
M tree returned by
the XSP engine processor is actually built by the generated program.
XSP pages are compiled into Cocoon producers. A producer is a Cocoon Java
type normally used to feed the initial XML content to the Cocoon processing
pipeline. For example, when Cocoon serves a static, "regular" XMLdo
cument,
file contents are actually delivered by Cocoon's built-in FileProducer.
Where JSP technology generate servlets, XSP generates producers instead. This
is because, among other reasons, the servlet modeldo
es not yet provide a
mechanism for portably and efficiently post-processing XML content.
JSP and XSP share many of the same built-in objects. XSP defines an abstract
producer (XSPPage) as the base class for generated programs. The request and
response are available with a slight change to the wrapper provided in Cocoon.
Access to ServeltOutputStreamObject and its associated writer are not provided.
HttpSession and ServletContext are provided as well.
XSP has a few additions to its object model. XspNodeStack is a java.util.Stack
used to control element nesting in the XSP pagedo
cument object;
xspCurrentNode
and xspParentNode are org.w3c.Node objects. xspParser is a Cocoon-supplieddo
M
parser, which may be used to create newdo
cuments and parse external XML
documents. In addition to the objects already listed, the XSPPage contains a
xspExpr() method than can be used to wrap any Java value as an org.w3c.Text
object. There is also an XSPUtil Class automatically imported that offers a
number ofdo
M, HTTP, and file manipulation services implemented as public
static methods. These include cloneNode, toMarkup encodeMarkup, formEncode,
formDecode, pathComponent, fileComponent, baseName, split, and isAlphaNumeric.
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"?>
Thedo
cument root element must be <xsp
age>
It must also have any language and Taglib declarations as attributes in the
<xspage> tag (e.g. <xspage 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 wholedo
cument, which generates
a resultdo
cument, 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 -->
<xspage 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 thedo
cument
root element of the XMLdo
cument 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 outputdo
cument.
-->
<page>
<p>This page has been requested <xsp:expr>count()</xsp:expr> times.</p>
</page>
</xspage>
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 originaldo
cument, 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
<xspage> 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
...
<xspage xmlns:example="http://www.oreilly.com/xspExample">
...
</xspage>
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 < items.length;
i++) {
<tr>
<td>
<xsp:expr>items.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 < someArray.length;
i++) {
<xsp:content>
<xsp:expr>someArray</xsp:expr>
</xsp:content>
<br/>
}
</xsp:logic>
The < and &
characters are special to XML parsers. When using them in files
they must occur < and &. 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.
Core tags
Each of the technologies has a set of core tags that are used throughout.
The XSP tag set consists of the following core tags.
<xspage> Root of all XSP pages and specifies the scripting language and
the tag libraries used by a particular XSP page
<xsp:structure> Top-level element encloses source program-level declarations
such as <xsp:include>. This element is used to import external module
definitions in a language-dependent way
<xsp:logic> Embeds procedural logic in an XSP page. Enclosed code is
transcribed verbatim into the generated XSPPage producer. Other XSP or user
markup may be nested inside this tag.
<xsp:content> Embeds "regular" XML content inside an <xsp:logic> block so
that no nested additional <xsp:logic> sections are required
<xsp:expr> Inlines a program expression as a Text node, except when used
directly inside another <xsp:> element, where it is substituted as an
expression, not a node. If you want to substitute an <xsp:expr> tag as
a node inside another XSP tag, you must enclose it in an <xsp:content>
element.
<xsp:element> Dynamically builds an element when its attribute values are
not known at compile time.
<xsp:attribute> Dynamically provides attribute values for a given element
(which can be specified statically as markup or dynamically by means of
<xsp:element>). It's typically used in conjunction with <xsp:expr>, where
the substituted expression is always cast to String
<xspi> Dynamically creates a processing instruction
<xsp:comment> Dynamically creates an XML comment
The JSP Reference syntax can be found on Sun's Java site.
Which Technology is Right for Me?
So which technology is best for your project? The answer: it depends.
There are pros and cons to both as we've seen, but each should be weighed
according to your project needs.
If you are looking for a solution that maximizes reusable code across
applications, then
XSP is probably your answer. XSP allows the separation
of content from presentation. This separation allows developers to handle
content generation. The XSP page can be generated from a servlet or other
Java code as well as being static. XML and XSL authors can handle presentation
and styling through modification of the XSL stylesheet applied to the XSP page.
Just as easily, XSP solves the other significant deficiency of JSP. Because
XSP processing occurs before any stylesheets are applied, the resultant XML
document can be transformed into any other format. This maintains all the
advantages of XML. The XSP page can be transferred between applications as
well as being used just for presentation.
If you want to keep your development teams clearly defined, then
, again,
XSP is probably your answer. The introduction of the JSP environment made
significant improvements in dynamic web application development by better
separating the application developer from the presentation designers. However
it still involves a fair amount of interaction between the two. There is
frequently a need for inline Java code to determine the correct presentation
necessary when dealing with dynamic content. Custom tag libraries have helped
address this and require the presentation person to be less knowledgeable about
what the logic is actuallydo
ing. But that person still needs to understand
how to use the tag library, which is usually more then
a presentation person
wants or needs to know.
XSP and accompanying framework focuses XSL and XSLT stylesheets for the
presentation layer written by presentation designers, XML for the content
provided by the content authors, and application logic layer and tagset
generated by the application developer. The interaction of the technologies in
the Cocoon framework is what glues everything together and allows XSL plus XML
plus embedded tags to generate an HTMLdo
cument. The tasks themselves are
clearly separated.
If your main concern is getting a product out thedo
or with the least risk
factor, then
JSP is your answer. JSPs are popular and widely understood, while
XSP and Cocoon are still emerging. This is not something to overlook. For large
scale projects, it is always necessary to evaluate how much effort it would take
to bring a new developer up to speed and the pool of talent you can draw from.
In addition, existing HTML and XML tools can be used for JSP development, making
the overall time it takes to get rolling relatively short.
02/22/2001
Overview
In the world of server page acronyms, XSP is gaining recognition.
It's the next evolution of server pages.
Sue Spielman will be speaking about XSP at the O'Reilly Conference on
Enterprise Java, March 26-29, in Santa Clara, California.
XSP stands for eXtensible Server Pages and is one of the core technologies
available in Cocoon. Cocoon is one of the seven current parts of the Apache
XML project. The new Cocoon paradigm is based on the fact thatdo
cument
content, style, and logic are often created by different individuals or
working groups. Cocoon aims for a complete separation of the three layers.
In other words, Cocoon allows content, logic, and style to be separated into
different XML files, and it uses XSL transformation capabilities to merge them.
While having similar concepts to Java Server Pages (JSP), there are a number
of differences present in XSP. We will look at both technologies to see how
they stack up against each other. This article assumes you have at least some
understanding of XML and its terminology.
XSP Technology
The main concept behind a web site using XML is the separation of content,
logic, and presentation. XSP provides the front-end portion of an XML
framework. Providing dynamic XML pages that are parsed and transformed by the
framework allows application interoperability, yet the pages are constructed
and stored as static files on a file system.
Just as Java is aimed at providing a clear separation of content from
application and business logic, XSP seeks to provide the same for XML-based
applications. Although many of the currently available XML frameworks allow
this separation of layers within compiled code, changes to the formatting of
actual data in an XMLdo
cument still require Java code and subsequent
recompilation.
XML browsers are useless without some predefined semantics. This is one of
the reasons why XSL (the eXtensible Stylesheet Language) was proposed and
designed. XSL is divided into two parts: transformation (XSLT) and formatting
objects (variously referred to as FO, XSL:FO, or simply XSL). Both are XML
DTDs that define a particular XML syntax: every XSL or XSLTdo
cument is a
well-formed XMLdo
cument.
The Cocoon publishing model is heavily based on XSLT's transformation
capabilities. XSLT allows complete separation of content and style, something
everyone writing web applications has been striving toward but has been
unsuccessful at. This separation is much harder to obtain with HTML, even if
CSS2 or other styling technologies are being used. But Cocoon goes further and
defines a way of separating content and style from the programming logic that
drives server-side behavior. The XSP language defines an XML DTD for separating
content and logic for compiled server pages.
In dynamic content generation technology, content and logic are combined.
There is typically a mix of static content and dynamic logic that work
together to create the final result, usually using run-time or time-dependent
input. XSP is no exception. It defines syntax to mix static content and
programmatic logic in a way that is independent of both the programming
language used and the binary results that the final source rendering generate.
It should be understood that XSP is just a piece of the framework. In much the
same way that formatting objects mix style and content, XSP objects mix logic
and content. On the other hand, since both are XML DTDs, XSLT can be used to
move from pure content to these final DTDs, placing the style and logic in the
transformation layers and guaranteeing complete separation and easier
maintenance.
JSP Technology
The intention of JSP technology was to provide a clean separation between
content and presentation. While making great strides indo
ing so, it falls
somewhat short. While JSP has simplified many of the server-side Java
programming details, it still can't quite make the clean break it was intended
to. If you have delivered a large-scale application using JSP you will no
do
ubt agree.
JSP mingles content (pure data) with presentation in the same way static HTML
does. JSP allows tags and inline Java code to be inserted into an otherwise
normal HTML page. When the JSP page is requested, the resulting code is
executed in a Servlet engine and the results are inserted right into the output
HTML. JSPs tend to be specific for an application because they are designed
from the outset for the delivery of output from that application. A typical
JSP pages contains static HTML/XML components, JSP tags, and optional snippets
of Java code called scriptlets. You can create and maintain JSP pages with your
favorite HTML/XML tool.
By using XML-like tags, scripting elements, scriptlets, and directives, a
content developer can accomplish quite a lot. Scripting elements and
expressions allow for runtime evaluation of variables. Directives can be
used to control certain aspects of the actual workhorse servlet's operation.
To simplify the scripting elements, a JSP developer has access to a number of
predefined variables such as request, response, in, and out. These variables
represent, respectively, HttPServletRequest, HttpServeletReponse, PrintWriter,
and BufferedReader. There are a few other predefined variables but for this
discussion those listed should suffice. Scriptlets provide a mechanism to
insert code into the servlet's service method. In addition, JSP can work
hand-in-hand with JavaBeans. By embedding beans within a JSP, it is possible
to encapsulate functionality for a JSP as well as reuse the bean in other
development efforts. Special treatment is given to beans in a JSP, which can
make for a cleaner, less cluttered JSP page. For example, parameter values
in a client request can automatically be used to set a bean's properties. Beans
also have scope and can be used per request, between pages, or even throughout
an application.
Custom Tag libraries also provide a way for JSP to separate content from
presentation. Using custom tag libraries it is possible to create business
logic that is almost completely hidden from the presentation developer. The
only thing that the presentation developer has to know is how to reference
the tag library and use the tag. This could be as simple as one line of code,
or it could be more complicated if tag interaction is required.
As you can see, JSP technology is very powerful and useful but is not ideal.
The Object Models
The XSP model works on the concept of processor and producers. A processor is
a Cocoon Java type that takes ado
M tree as input and produces another
(possibly modified)do
M tree as output. Think of it as a filter in a command
pipeline. The XSP engine is implemented as a Cocoon processor that accepts an
XSP page as input. The first time a given XSP page is processed, it is
translated into an equivalent source program that is then
compiled, loaded,
and executed. Subsequent requests for the same XSP page result in the execution
of the generated program. As you may expect, the outputdo
M tree returned by
the XSP engine processor is actually built by the generated program.
XSP pages are compiled into Cocoon producers. A producer is a Cocoon Java
type normally used to feed the initial XML content to the Cocoon processing
pipeline. For example, when Cocoon serves a static, "regular" XMLdo
cument,
file contents are actually delivered by Cocoon's built-in FileProducer.
Where JSP technology generate servlets, XSP generates producers instead. This
is because, among other reasons, the servlet modeldo
es not yet provide a
mechanism for portably and efficiently post-processing XML content.
JSP and XSP share many of the same built-in objects. XSP defines an abstract
producer (XSPPage) as the base class for generated programs. The request and
response are available with a slight change to the wrapper provided in Cocoon.
Access to ServeltOutputStreamObject and its associated writer are not provided.
HttpSession and ServletContext are provided as well.
XSP has a few additions to its object model. XspNodeStack is a java.util.Stack
used to control element nesting in the XSP pagedo
cument object;
xspCurrentNode
and xspParentNode are org.w3c.Node objects. xspParser is a Cocoon-supplieddo
M
parser, which may be used to create newdo
cuments and parse external XML
documents. In addition to the objects already listed, the XSPPage contains a
xspExpr() method than can be used to wrap any Java value as an org.w3c.Text
object. There is also an XSPUtil Class automatically imported that offers a
number ofdo
M, HTTP, and file manipulation services implemented as public
static methods. These include cloneNode, toMarkup encodeMarkup, formEncode,
formDecode, pathComponent, fileComponent, baseName, split, and isAlphaNumeric.
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"?>
Thedo
cument root element must be <xsp
age> It must also have any language and Taglib declarations as attributes in the
<xsp
age> tag (e.g. <xspage 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 wholedo
cument, which generates
a resultdo
cument, 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
age 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 thedo
cument
root element of the XMLdo
cument 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 outputdo
cument.
-->
<page>
<p>This page has been requested <xsp:expr>count()</xsp:expr> times.</p>
</page>
</xsp
age>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 originaldo
cument, 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
age> xmlns attribute in the XSP case. The Cocoon properties file alsoneeds 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
age xmlns:example="http://www.oreilly.com/xspExample">...
</xsp
age>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 < items.length;
i++) {
<tr>
<td>
<xsp:expr>items.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 < someArray.length;
i++) {
<xsp:content>
<xsp:expr>someArray</xsp:expr>
</xsp:content>
<br/>
}
</xsp:logic>
The < and &
characters are special to XML parsers. When using them in files
they must occur < and &. 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.
Core tags
Each of the technologies has a set of core tags that are used throughout.
The XSP tag set consists of the following core tags.
<xsp
age> Root of all XSP pages and specifies the scripting language andthe tag libraries used by a particular XSP page
<xsp:structure> Top-level element encloses source program-level declarations
such as <xsp:include>. This element is used to import external module
definitions in a language-dependent way
<xsp:logic> Embeds procedural logic in an XSP page. Enclosed code is
transcribed verbatim into the generated XSPPage producer. Other XSP or user
markup may be nested inside this tag.
<xsp:content> Embeds "regular" XML content inside an <xsp:logic> block so
that no nested additional <xsp:logic> sections are required
<xsp:expr> Inlines a program expression as a Text node, except when used
directly inside another <xsp:> element, where it is substituted as an
expression, not a node. If you want to substitute an <xsp:expr> tag as
a node inside another XSP tag, you must enclose it in an <xsp:content>
element.
<xsp:element> Dynamically builds an element when its attribute values are
not known at compile time.
<xsp:attribute> Dynamically provides attribute values for a given element
(which can be specified statically as markup or dynamically by means of
<xsp:element>). It's typically used in conjunction with <xsp:expr>, where
the substituted expression is always cast to String
<xsp
i> Dynamically creates a processing instruction<xsp:comment> Dynamically creates an XML comment
The JSP Reference syntax can be found on Sun's Java site.
Which Technology is Right for Me?
So which technology is best for your project? The answer: it depends.
There are pros and cons to both as we've seen, but each should be weighed
according to your project needs.
If you are looking for a solution that maximizes reusable code across
applications, then
XSP is probably your answer. XSP allows the separation
of content from presentation. This separation allows developers to handle
content generation. The XSP page can be generated from a servlet or other
Java code as well as being static. XML and XSL authors can handle presentation
and styling through modification of the XSL stylesheet applied to the XSP page.
Just as easily, XSP solves the other significant deficiency of JSP. Because
XSP processing occurs before any stylesheets are applied, the resultant XML
document can be transformed into any other format. This maintains all the
advantages of XML. The XSP page can be transferred between applications as
well as being used just for presentation.
If you want to keep your development teams clearly defined, then
, again,
XSP is probably your answer. The introduction of the JSP environment made
significant improvements in dynamic web application development by better
separating the application developer from the presentation designers. However
it still involves a fair amount of interaction between the two. There is
frequently a need for inline Java code to determine the correct presentation
necessary when dealing with dynamic content. Custom tag libraries have helped
address this and require the presentation person to be less knowledgeable about
what the logic is actuallydo
ing. But that person still needs to understand
how to use the tag library, which is usually more then
a presentation person
wants or needs to know.
XSP and accompanying framework focuses XSL and XSLT stylesheets for the
presentation layer written by presentation designers, XML for the content
provided by the content authors, and application logic layer and tagset
generated by the application developer. The interaction of the technologies in
the Cocoon framework is what glues everything together and allows XSL plus XML
plus embedded tags to generate an HTMLdo
cument. The tasks themselves are
clearly separated.
If your main concern is getting a product out thedo
or with the least risk
factor, then
JSP is your answer. JSPs are popular and widely understood, while
XSP and Cocoon are still emerging. This is not something to overlook. For large
scale projects, it is always necessary to evaluate how much effort it would take
to bring a new developer up to speed and the pool of talent you can draw from.
In addition, existing HTML and XML tools can be used for JSP development, making
the overall time it takes to get rolling relatively short.