| The servlets need to output XML and call an XSLT processor to turn it into HTML. If every servlet is calling the XSLT processor, it makes sense to encapsulate this behavior in a library. The library, in this chapter, is called XslServlet . Encapsulating the XSL Processor Figure 8.1 shows the UML class model for the library. The main classes are as follows : -
XslServlet ”Extends HttpServlet and redirects HTTP requests to XSL-enhanced versions of doGet() and doPost() . -
XslServletLiaison ”An interface for an additional parameter of the XSL-enhanced version of doGet() and doPost() . As its name implies, it establishes the liaison with the XSLT processor. -
XslServletLiaisonImpl ”An implementation of XslServletLiaison specialized for Xalan. If you're using another XSLT processor, you must provide another implementation of XslServletLiaison . -
XslWriter ”Derived from PrintWriter , it provides helper methods to escape XML delimiters such as < . -
BugList and BugForm ”Examples of servlets built with the XslServlet library. They inherit from XslServlet instead of inheriting directly from HttpServlet . Figure 8.1. The XslServlet library encapsulates the XSL processor.  Introducing Pesticide To illustrate the use of XslServlet , you will write a Web-based bug tracker called Pesticide. Hopefully, the name will have a dissuasive effect on your code. As always, your focus is on the application of XML, not on building an industrial-strength bug tracker. Therefore, some simplifications will be made: -
Bug descriptions are limited to the essentials ”a name, description, programmer, and application name. -
No mechanism exists to add new applications or programmers, other than typing SQL commands. -
No workflow management exists to notify programmers when new bugs have appeared. Figure 8.2 is Pesticide's main screen. As you can see, it centers on the list of bugs. Figure 8.2. Pesticide is a Web-based bug tracker.  |
