5.8 Six Ways to Skin a Servlet Cat

Java Servlet Programming, 2nd Edition > 5. Sending HTML Information > 5.8 Six Ways to Skin a Servlet Cat

< BACK

CONTINUE >

In the time since the first edition of this book, servlets have become the de facto standard for Java-based server-side web development. The Darwinistic battle between servlets, server-side applets, and other Java-based pluggable architectures has effectively ended and servlets have been declared the winner, supported today in every web server and application server. The new area of active innovation can be found above the servlet layer, at the presentation and framework levels, where individuals and companies are exploring how best to build on top of servlets to create effective web sites.

Such solutions are needed because the simple approach to generating markup content, having the servlet programmer write an out.println( ) call for each content line, has proven to be a serious problem for real-world use. With the out.println( ) approach, markup content has to be created within code, and that becomes an onerous and time-consuming task for long pages. In addition, page creators have to ask developers to make all site changes.

The goal nearly all content creation architectures share is to "separate content from presentation." The term content here means the raw data of the site and the manipulation of that data. A better term perhaps would be data processing, but to "separate data processing from presentation" doesn't seem to have the right ring to it. The term presentation means the representation of the data given to the end user (often HTML, although with the growth of web-connected devices it's increasingly likely to be WML, the Wireless Markup Language). Separating content from presentation gives several advantages, primarily easier site creation and maintenance because the content of the page (controlled by a programmer) can be developed and changed independently of the presentation of the page (controlled by a designer or producer). Some refer to this separation as a Model-View-Controller (MVC) architecture. The model is synonymous with content, the view is synonymous with presentation, and the controller squeezes in at various places depending on the technology.

Later in the book, we'll take a closer look at a number of popular alternatives for servlet-based content creation. For each alternative we'll provide some background on the tool, demonstrate how to use the tool, and examine where the tool works best. Because of space and time considerations and the fact that every project mentioned is a quickly moving target, we cannot provide a full tutorial for each alternative. One thing to be clear about: these are more than just five different implementations of the same idea. Each alternative approaches the content creation problem from a different angle, and as a result the techniques for solving the problem vary widely. A tool that works well in one situation might not work so well in another situation. One size does not fit all here. So don't read the examples in these chapters looking for the best technology. Look instead for the best technology for your project.

We have avoided discussion of proprietary commercial solutions because of the inherent risk in tying to a single-vendor solution influenced by the financial motivations of the commercial vendor.^[2] The alternatives discussed later in the book are as follows:

^[2] We learned this the hard way. In the first edition of this book we covered the commercial htmlKona package from WebLogic because there was no similar alternative and because we were assured by WebLogic that it would remain available at a reasonable price. After WebLogic was purchased by BEA Systems, that assurance could not be counted upon, and in fact htmlKona became a minor footnote on the BEA Systems price sheet. Happily, htmlKona was reimplemented as the open source Element Construction Set (ECS) Project through the Apache Jakarta Project and will now be available and maintained as long as people are interested in the project.

JavaServer Pages: JavaServer Pages (JSP) is a technology created by Sun Microsystems and closely tied to servlets. As with servlets, Sun releases a JSP specification, and third-party vendors compete on their implementation of that standard. Being released by Sun puts JSP in a very privileged position, and had JSP solved a sufficient number of user problems it would probably have won the market before there were any other viable entries. As is, a surprising number of users are disenchanted with JSP and alternatives are gaining popularity. See Chapter 18, and http://java.sun.com/products/jsp.
Tea: Tea is a newly open sourced product from the Walt Disney Internet Group (formerly GO.com), created internally over the years to solve their tremendous web production needs for sites such as ESPN.com. It's similar to JSP although it avoids many of JSP's problems and already has terrific tools support. See Chapter 14, and http://opensource.go.com.
WebMacro: WebMacro is a template engine created by Semiotek, Inc., as part of the Shimari project and possibly merging into the Apache Jakarta Project. Many template engines could be discussed, however WebMacro has the largest mindshare, has been used on extraordinarily high-traffic commercial sites such as AltaVista.com, has been integrated in open source frameworks such as Turbine and Melati, and has been used in prominent open source projects such as JetSpeed. In addition, see Chapter 15, and http://webmacro.org and http://jakarta.apache.org/velocity.
Element Construction Set: The Element Construction Set (ECS) package from the Apache Jakarta Project is a set of classes modeled after the htmlKona product from WebLogic (now BEA Systems). ECS has many limitations, but it solves a certain class of problems, and looking at the ECS approach provides a good base for discussing the more flexible XMLC. See Chapter 16, and http://jakarta.apache.org/ecs.
XMLC: XMLC makes use of XML to get nearly all the power of ECS without many of its limitations. It was created by Lutris as part of their open source Enhydra Application Server and can be used as a separate component. See Chapter 17, and http://xmlc.enhydra.org.
Cocoon: Cocoon is another XML-based alternative created by the XML Apache Project. Cocoon uses XML and XSLT to manage content and create what has often been referred to as a web publishing framework. Cocoon is a servlet-driven framework whereby XML content, either static or dynamically created, is run through an XSLT filter before presentation to the client. That filter may format the content as any content type including HTML, XML, WML, or PDF and the framework may choose different filters depending on the client. We won't discuss Cocoon at length in this book because it has more to do with XSLT programming than Java programming, and because (at least right now) it's generally not the tool of choice for writing interactive web applications. It's better suited for large scale mostly static sites that want to allow multiple views on their content. For more information on Cocoon see http://xml.apache.org and the book Java and XML by Brett McLaughlin (O'Reilly). The Java and XML chapter covering Cocoon is available online for free at http://www.oreilly.com/catalog/javaxml/chapter/ch09.html.

If your favorite tool, or a popular tool, isn't mentioned, it's not surprising. Look at the date of your tool's creation: it's probably after this book went to press. The innovation taking place in this area is tremendous, and with XML providing us with new abilities and web-enabled devices making demands for new features, this area is ripe for new entries. Also, please understand that enhancements to these tools are coming at a breakneck pace. Each tutorial chapter is sure to be at least slightly out of date by the time you read this. To help you stay current, be sure to check out http://www.servlets.com.

< BACK

CONTINUE >