Enhydra XMLC Java Presentation Development: Presentation Technologies
In This Chapter
- Publishing Frameworks for Adapting to the Future
- Servlet Presentation Programming
- JavaServer Pages
- JSP TagLibs
- Cascading Style Sheets
- Final Comparative Discussion
- Templates, MVC, and XMLC
In the world of Web development, there are many, many ways to skin a cat. Or, in our case, skin a Web application. Perl, Tcl, Java, Python, ASP, and many other languages and tools bring different strategies for building Web applications to the table. In the case of Java alone, there are many frameworks that leverage some level and combination of Java, XML, and/or XSLT.
Each strategy represents strengths and pitfalls that will vary depending on your background, training, development style, prejudices, preferences, and long-term goals. No one technology represents a "boil the oceans" solution. The only way to select the right tool is to survey the field and make an informed decision. This chapter will attempt to introduce the models and strategies of some of the nearest competitive technologies to Enhydra XMLC.
The presentation-building strategies we'll introduce include simple servlet programming, JavaServer Pages, XSLT, and Cocoon. In this non-exhaustive survey, the goal will be to flesh out some of the unique value in each technology for generating Web presentations. Where the opportunity presents itself, I'll throw in some comparison comments with XMLC to capitalize on a particular aspect of presentation development. In doing so, I hope to give you a better backdrop for understanding XMLC's world through reasonable comparison and contrast.
All the technologies reviewed in this chapter are also supported in Enhydra 3 and 4, including XSLT. The lone exception is Cocoon, which can easily be integrated into the Enhydra environment.
Publishing Frameworks for Adapting to the Future
The dynamic beginnings of the Web started with Perl CGI scripting. Perl scripts heavily leveraged print statements to spit out hardcoded HTML. Servlet programming and JavaServer Pages do much the same. It wasn't until later that developers started to see the limitation to this approach. When it was time to make changes to the presentation, what was fun to build was not as fun to maintain.
Perhaps this style of generating markup language is coming to an end, as the development world moves to adopt device-independent strategies in preparation for the black box of a device-crazy world. Is your application prepared to adopt yet another set of clients enabled by yet another W3C specification? After all, HTML is no longer the only game in town.
The good news is that there are plenty of technologies and publishing frameworks (explained in detail later in this chapter) from which to select. From simple Web page presentations to generating PDF files on the fly, there's a framework for you. Even JavaServer Pages has addressed many of its criticisms with the introduction of Taglibs. And, if you are prepared to add an entirely new dimension of programming to your projects, Apache's Cocoon is a promising new technology to watch as well.
All these approaches can be categorized into one of three camps. Of course, simple servlet development is the least structured style of presentation development, where the developer acts as HTML designer and developer, interweaving hard-coded HTML print statements side-by-side with other Java logic.
Template engines, on the other hand, permit the document to drive. At least they appear to be a step in a document-oriented direction. JSP, WebMacro (http://www.webmacro.org), and Apache's Velocity are examples of template strategies that insert markup-generating logic between the lines of static markup language. Taken from Velocity's Mud Store example, the following example of Velocity Template Language (VTL) reflects the nature of template engines to insert an intermediate, embedded language directly in the markup document:
<HTML> <BODY> Hello $customer.Name! <table> #foreach( $mud in $mudsOnSpecial ) #if ( $customer.hasPurchased($mud) ) <tr> <td> $flogger.getPromo( $mud ) </td> </tr> #end #end </table>
Finally, there's DOM manipulation. This is also a templating mechanism, but it introduces an object-oriented way of representing the template as a document tree that can be manipulated "from afar" by Java logic, thus avoiding the error-prone embedded logic approach, in addition to other limitations. Cocoon, XSLT, and XMLC are implementations of the DOM approach.
Presentation Versus Publishing Frameworks
Cocoon and others refer to their technology platforms as publishing frameworks. Cocoon, for example, can generate XML, XHTML, and PDF documents from source XML files. XMLC can do the same, including the generation of XML-based SVG (W3C's Scalar Vector Graphics). There is another class of technology beginning to emerge that focuses on interactive user interfaces. These presentation frameworks resurrect the environment of Swing and Motif, repositioning the topic as one of interacting with the user through user interface components, as opposed to altering and presenting documents.
Jakarta's Struts and Apache's Turbine are examples of a new category of frameworks that are more presentation-oriented. Enhydra's Barracuda is an exciting new project that addresses the presentation framework category for XMLC. For the XMLC community, Barracuda is the one to watch for those seeking a componentized, event-driven GUI library strategy for generating Web presentations.
Our perspective will ask the questions, "What do all these technologies mean to real-world development by professional design and development organizations? What do they mean in terms of product lifecycle, time to market, and life in general? And, of course, how do they compare with Enhydra XMLC?" Keep the following points in mind:
Cutting edge Web presentations require high-end designers, commonly working with a third party, highly talented "backend" Java development team. What will the chosen technologies require in terms of training, and how will these technologies impact cooperative development, particularly if the teams are separated by a significant distance?
The customers of these presentations are more savvy now. They know there are technologies for separating logic and markup language. Add to that corporate IT's insistence that the technology you use comply with "standards."
The framework you choose will affect your ability to react quickly to changing requirements. Cocoon is very cool, but how long will it take a newbie to ramp up? Is it good enough to know Java, or will they need to learn two languages?
Let's now spend the rest of this chapter taking a look at some pretty interesting strategies for generating Web presentations. Again, we're going to do this for the purpose of finding ways to better explain XMLC development and how it differs from other strategies. By the end of the chapter, when all the smoke has cleared, we'll be ready to spend the rest of this book in XMLC development.