Download (direct link):
Listing 28.7 htmlstates.xsl
Some Direction about JSP Reuse and Content Delivery 255
Design patterns serve as building blocks for propagating best practices in software development. In our sample application, the MVC and Front Controller patterns demonstrate how to avoid programming pitfalls that inevitably reveal themselves in superfluous code that is hard to maintain and deploy. The migration of our configuration mappings to our deployment descriptor helped our application management, and the getNamedDispatcher method helped avoid the hard-coding of context paths in our application. The dispatcher component manages the application navigation and display views. Applications and program paths change during normal development lifecycles, and when business logic is spread across your application, they become very difficult to maintain and modify.
Additionally, when control logic is moved into a controller class, processing is facilitated because all requests are coordinated and an application's business logic is centralized. A controller servlet application is also employed by a popular Apache Software Foundation offering called the Struts framework, mentioned in Item 24, which is a much more sophisticated application than the one demonstrated in our example and has been well received by the development community. Servlet controllers and XML transform filters can be a powerful combination when processing user requests, specifically SOAP requests. One shortcoming that needs mention is that a single servlet controller can become unmanageable when too much business logic is transferred into the application, which would warrant additional controllers.
Lastly, filter applications are important architectural considerations that need to be included in all enterprise development design decisions. Essentially, they are building blocks that allow applications to layer logic and transform user requests, which allow developers to promote reuse.
Item 29: Some Direction about JSP Reuse and Content Delivery
Your boss just asked you to storyboard his latest and greatest business plan so that it could be shown to local and remote management teams at next week's status meeting. Your previous development experience involved crafting Java Swing components for the accounting department and building some static HTML pages for your office lottery selections.
You've determined that in order to satisfy your requirement to serve both local and remote users, your application should run in a browser, and that JavaServer Pages would be a perfect vehicle to serve up dynamic content. When you asked your boss about the content needed for the presentation, his reply was that it was still being worked on, and it was possible that it could be published by one of those remote management teams that will participate in next week's meeting. His response has led you to believe that a simple content management application might be needed to accommodate the inclusion of dynamic content from this remote source.
Your task appears to be a lot of work to deliver in one week's time, but with a better understanding of JSP page fragmentation and dynamic content inclusion, you should have a pretty good chance of making yourself and your boss look good. JSP page fragmentation will allow the application to be reusable and fairly maintainable, which
256 Item 29
means that additional functionality can be added without having to rewrite the entire application. The most difficult aspect of this task will be obtaining content from a different context than the application being executed, but we'll look into that later.
Certainly, every development effort should start with a simple storyboard to envision what the application might look like. Figure 29.1 is a start.
Not only will your storyboard show spatial relationships and interface behaviors, it will also allow you to organize your files into subdirectories to make them easier to identify and maintain. In our case, we'll need two file structures, one for the default application, and another for the remote location to drop in content.
Now that your look and feel has been determined, we'll add our page fragments in a file called home.jsp, displayed in Listing 29.1. The JSP include directive on line 06 reads, translates, and pastes the specified file (header.jsp) into your JSP page one time only. If any modifications are made to your header.jsp code, your Web container will need to retranslate the code to reflect these changes. The JSP include action on line 74 includes the footer.jsp page during request time. The include action is more robust than the directive because it performs an automatic update dynamically.
leftnav.jsp Content is displayed here from a separate context
<param name = "title" value = "" />
Figure 29.1 Application storyboard.
Some Direction about JSP Reuse and Content Delivery 257
01 <%@ taglib uri="http://java.sun.com/jstl/ea/core" prefix="c" %>