Chapter 10. Web Publishing Frameworks

This chapter begins our examination of specific Java and XML topics. I have covered the basics of using XML from Java, looking at the SAX, DOM, JDOM, and JAXP APIs to manipulate XML, and the fundamentals of using and creating XML itself. Now that you have a grasp on using XML from your code, I want to spend time on specific applications. The next six chapters cover the most significant applications of XML, and, in particular, how those applications are implemented in the Java space. While there are literally thousands of important applications of XML, the topics in these chapters are those continually in the spotlight, with the potential to significantly change the way traditional development processes occur.

The More Things Change, the More They Stay the Same Readers of the first edition will find that much of the Cocoon discussion in this chapter is the same. Although I promised Cocoon 2 would be out by now and expected to be writing a chapter on it, things haven't progressed as quickly as expected. Stefano Mazzochi, the driving force behind Cocoon, finally got around to finishing school (good choice, Stefano!), and development on Cocoon 2 slowed as a result. Cocoon 1.x is still the current development path, so stick with it for now. I've updated the section on Cocoon 2 to reflect what is coming. Keep an eye out for more Cocoon-related books from O'Reilly in the months to come.

The first hot topic I look at is the XML application that has generated the most excitement in the XML and Java communities: the web publishing framework. Although I have continually emphasized that generating presentation from content is perhaps overhyped compared to the value of the portable data that XML provides, using XML for presentation styling is still very important. This importance increases when looking at web-based applications.

Virtually every major application I can find is either completely web-based or at least has a web frontend. At the same time, users are demanding more functionality, and marketing departments are demanding more flexibility in look and feel. The result has been the rise of the web artist; this new role is different from the webmaster in that little to no Perl, ASP, JavaScript, or other scripting language coding is part of the job description. The web artist's entire day is comprised of HTML and WML creation, modification, and development.[16] The rapid changes in business and market strategy can require a complete application or site overhaul as often as once a week, often forcing the web artist to spend days changing hundreds of HTML pages. While Cascading Style Sheets (CSS) have helped, the difficulty of maintaining consistency across these pages requires a huge amount of time. Even if this less-than-ideal situation were acceptable, no computer developer wants to spend his or her life making markup language changes to web pages.

[16]"HTML and WML" includes the tangential technologies used with the markup language. These complementary technologies, like Flash and Shockwave, are not trivial, so I'm by no means belittling these content authors.

With the advent of server-side Java, the problem has only grown. Servlet developers find themselves spending long hours modifying their out.println( ) statements to output HTML, and often glance hatefully at the marketing department when changes to a site's look require modifications to their code. The entire Java Server Pages (JSP) specification arguably stemmed from this situation; however, JSP is not a solution, as it only shifts the frustration to the content author, who constantly has to avoid making incidental changes to embedded Java code. In addition, JSP does not provide the clean separation between content and presentation it promises. A means to generate pure data content was called for, as well as a means to have that content uniformly styled either at predetermined times (static content generation) or dynamically at runtime (dynamic content generation).

Of course, you may be nodding your head at this familiar problem if you have ever done any web development, and hopefully your mind is wandering into the XSL and XSLT technology space. The problem is that an engine must exist to handle content generation, particularly in the dynamic sense. Having hundreds of XML documents on a site does no good if there is no mechanism to apply transformations on request. Add the need for servlets and other server-side components to output XML that should be consistently styled, and you have defined a small set of requirements for the web publishing framework. In this chapter, I take a look at this framework, how it allows you to avoid long hours of HTML coding, and how it helps you convert all of those "web artists" into XML and XSL gurus, allowing applications to change look and feel as often as desired.

A web publishing framework attempts to address these complicated issues. Just as a web server is responsible for responding to a URL request for a file, a web publishing framework is responsible for responding to a similar request; however, instead of responding with a file, it often will respond with a published version of a file. In this case, a published file refers to a file that may have been transformed with XSLT, massaged at an application level, or converted into another format such as a PDF. The requestor does not see the raw data that may underlie the published result, but also does not have to explicitly request that publication occur. Often, a URI base (such as http://yourHost.com/publish) signifies that a publishing engine that sits on top of the web server should handle requests. As you may suspect, the concept is much simpler than the actual implementation of a framework like this, and finding the correct framework for your needs is not a trivial task.

9.5. What's Next?		10.2. Installation

Copyright © 2002 O'Reilly & Associates. All rights reserved.