In the example used throughout this chapter, taken from the sample app accompanying this tutorial, we've seen how good MVC design practice makes it possible to change view technology without changing a line of controller or model code. JSP, although one of the core J2EE specifications, is only one of many choices for view technology. In this chapter, we've looked at JSP along with several leading alternatives, considering the advantages and disadvantages of each and when you might choose to use it. We considered the following alternative view technologies, demonstrating how they can be integrated with MVC web apps in practice:

None of these view technologies is perfect and none is right for all projects. In addition to the inherent strengths and weaknesses of each technology, the availability of skills will be an important consideration on a project-by-project basis. JSP has the advantage of inclusion in the core J2EE standards. It is an excellent view technology, so long as its use is subject to strict discipline. We've looked at coding standards to ensure that JSP pages are maintainable. Strict coding standards are essential, as the consequences of abusing JSP are severe, and often seen in practice. The release of the JSP Standard Template Library in 2002 is a huge advance for JSP, and the JSTL should be viewed as an essential part of JSP, to be used in every app using JSP. JSP 2.0 will move this library's expression language into the JSP core, and introduce further enhancements that move the JSP model away from the largely discredited reliance on scriptlets typical of most JSP pages in the past. The Velocity template language is a simple, effective view technology that is a good choice for many apps. It's simpler than JSP and easier for HTML developers to learn, offering only the features needed to implement clean views, and none of the temptations that still afflict JSP. Velocity macros are particularly neat, providing a simple and effective way of reusing common content without the need for Java coding. As we'll see in , Velocity offers excellent performance. XSLT and XMLC provide two very different models to JSP and template languages such as Velocity, each providing good separation of presentation from dynamic content generation. Their appropriateness in a project will depend on the overall authoring strategy. As we've seen, it's even possible to mix different view technologies in the one app. We considered the use of XSLT within JSP pages. There's also no reason why we can't use, say, Velocity for some views and JSP pages for others. This may allow us to benefit from the strengths of individual technologies to solve specific problems. However, the downside to such mixing is that it complicates deployment and increases the range of skills required to develop and maintain an app. Certainly there is no difficulty in a well-designed app in generating a few views using different technologies - for example, to make some content available in the form of PDF documents.


Remember that the choice of view technology shouldn't have a profound impact on app design. Sometimes the choice of view technology may flow naturally from the app's business requirements and architecture. For example, if data exists within the app as XML, XSLT views may be an obvious choice. However, in general it should be possible to choose between view technologies without changing the app's architecture. Business logic components and even web tier controllers should be unaffected by a change of view technology.


A personal note: Before the release of the JSP Standard Tag Library, I'd come to question whether JSP was a wise choice for most apps. The JSTL negates a lot of the valid criticisms leveled at JSP in the past, and provides a sound basis for app views. While XML-based scripting (as offered by all JSP custom tags, including JSTL tags) can still be clumsy, JSP with JSTL offers a powerful, relatively simple, solution for most requirements.


Whatever view technology you choose, remember to document the model objects exposed by your web tier controllers thoroughly. This amounts to a contract between controllers and views.

We also looked at view composition: the building of complex views from multiple building blocks, which may be the output of other views or page components such as included JSP pages. We saw how this can be achieved using our MVC framework, regardless of the view technology we use.

In the next chapter, we'll look at deployment issues. In , we'll look at the important topic of performance tuning and testing, including benchmarks for some of the view technologies discussed in this topic and the issue of HTTP caching.