This chapter is from the book
This chapter is from the book
This chapter is from the book
Cocoon
Cocoon is a very interesting project that has both a great deal of promise and a huge challenge to make itself relevant to a large audience. Unlike JSP and much like XMLC, the Apache Cocoon project views the world through the eyes of XML. But rather than rely on Java for DOM manipulation as XMLC does, Cocoon goes the route of emergent technologies XSLT and formatting objects. At the same time, XSP does indeed take on JSP-like features when embedded Java manipulation is an option.
How wedded to XML is Cocoon? So much so that the Cocoon project page points out that Cocoon is not appropriate for generating standard HTML output, because HTML is inherently not well-formed XML. Obviously, XHTML support in future browsers will be important for the successful adoption of Cocoon.
The Cocoon framework supports three steps of content and presentation delivery:
XML creation addresses the role of the content owners. These are the experts in their field; for example, fly fishermen writing about fly fishing.
XML processing takes place. This is where programming logic is applied to the content, such as fetching descriptions and prices for very expensive fishing lures.
XSL rendering delivers the end result to the client, using an XSL stylesheet to transform the presentation into HTML, WML, or other popular formats.
XSP for Dynamic Content Creation
At first glance, XSP (eXtensible Server Pages) appears similar to JSP. Its role is to complement the static content contained in XML documents with dynamic content as fetched, for example, from a database or a live news feed. However, as you'll soon see, XSP is a more flexible, Java-independent language that melds more gently with its host markup language.
If you think XSP markup looks suspiciously like a custom tag from a JSP tag library, you'd be right. Cocoon has its own implementation of tag libraries. This is how the Cocoon project can maintain that it separates logic for the creation of dynamic content from markup, thus respecting the needs for the roles of designers and developers. Tag libraries remove the complete reliance on procedure-based XSP code, shown in this example:
<table>
<xsp:logic>
for (int i=0; i < items.length; i++) {
<tr>
<td>
<xsp:content>
<xsp:expr>items[i].getName()</xsp:expr>
</xsp:content>
</td>
</tr>
}
</xsp:logic>
</table>
In this example, XSP cannot escape the fact that XML parsers treat < and & characters uniquely, therefore leading to the requirement of using < in the for loop. Also, expressions cannot be imbedded directly inside areas of XSP Java logic without being encapsulated with <xsl:content> tags. XSP makes coding a bit simpler than JSP, such as automatically casting all Java types to strings.
Even with XSP, you can see how heavily Cocoon relies on XSL. XSP uses XSLT stylesheets for source code generation. Each tag maps to an XSLT template. The template generates the supporting program logic to implement the tag's stated purpose. It is this underlying mechanism that makes just about any scripting language besides Java a candidate for supporting Cocoon XSP development.
Cocoon Trade-Offs
Cocoon is an excellent option for a publishing house, such as a journal or newspaper Web site, where the functionality of the site is defined in a structured, consistent way. Users expect these presentations to be consistently displayed from issue to issue.
The flipside is that Cocoon is a rather large, complex system. As the Apache Cocoon site acknowledges, its processing complexity is not well-suited for real-time operation on the server. In order to overcome performance challenges, a great deal of effort is going into compiler strategies and caching techniques.
The issue for Cocoon is that, like XMLC, it is butting heads with JSP. XSP versus JSP development is probably perceived as more contentious an issue as compared to these technologies and XMLC, which avoids the embedding of Java in HTML or XML. Cocoon must also help XSL's formatting objects emerge as a standard. To date, whereas XSLT is enjoying a great deal of popularity, FOs have only seen acceptance within the Cocoon project.
If the presentation results require a lot of on-the-fly processing, XMLC is the better option, always showing the users the same view from their requests.
Note
So how was it that Lutris Consulting gained firsthand experience with JSP even before it came up with XMLC? Well, it wasn't JSP, it was JDDI, an invention of Lutris' before JSP hit the market. It did some things very similar to JSP, including embedding Java inside HTML pages and supporting a macro language for conditional selection of Java code. What became of JDDI? Well, it's still in Enhydra 3.