Chapter 13: Views in the Web Tier

Overview

In the last chapter we focused on how web applications should handle control flow and access business objects. In this chapter, we'll look closely at view technologies for J2EE web applications.

The choice of view technologies can - and should - be largely independent of web application workflow. We'll begin by looking at the advantages of decoupling views from controller components. We'll then survey some leading view technologies for J2EE web applications. We'll look at the advantages and disadvantages of each, enabling you to make the correct choice for each project.

While it is essential that the J2EE standards define at least one approach to markup generation, the special recognition given to JSP in the J2EE specifications has some unfortunate consequences. JSP is a valuable way of rendering content, but merely one of many valid alternatives. Hopefully, the previous chapter has made a convincing case that servlets and delegate Java objects ("controllers"), not JSP pages, should be used to control workflow in the web tier. By bringing much of the power of the Java language into presentation templates, JSP introduces as many dangers as benefits. When we use JSP pages, it's vital to adopt strict standards to ensure that these dangers don't create serious ongoing problems.

In this chapter, we'll take an open-minded look at JSP and some leading alternative view technologies for J2EE applications and how to decide which view technology is best to solve a given problem. We'll look at the strengths and weaknesses of each of the following view technologies, and look at them in use:

• JSP. We'll look at traps that must be avoided in using JSP, and how best to use JSP pages to ensure that web applications using them are clean and maintainable. We'll look at the new JSP Standard Template Library (JSTL), which provides valuable assistance in helping JSP pages function as effective view components.

• The Velocity template engine. This is a simple, easy-to-learn templating solution that isn't tied to the Servlet API. This is an important bonus, as it can enable templates to be tested outside an application server.

• Approaches based on XML and XSLT. XSLT offers very powerful content rendering and a good separation between presentation and content, at the cost of a potentially complex authoring model and a substantial performance overhead.

• XMLC, a DOM-based content generation approach introduced in the Enhydra application server, which enables dynamic pages to be created from static HTML mockups.

• Solutions enabling the generation of binary content. While these aren't alternatives to the markup-oriented view technologies listed above, any well-designed web application must be able to generate non-markup content if necessary. We use the example of PDF generation - a common requirement that illustrates the challenges posed by the generation of non human-readable and binary formats, and how we can overcome them in an MVC design.

Important 

Whatever view technology we use, we should not need to modify code in controllers. If we adopt the MVC web architecture we looked at in Chapter 12, controllers and views are completely decoupled.

Choosing the right view technology for a project is important because it can make it a lot easier to meet presentation requirements. However, the choice can - and should - be made largely independently of the rest of the application code.

The deciding factors are likely to be:

• How well the given solution fits the problem. A good guide here will be the volume and complexity of code required for each solution.

• Performance considerations. We'll consider some major performance issues in this chapter, while in Chapter 15 we look at benchmarks for some of the view technologies discussed here.

• Skills in the project team. For example, if a team has strong JSP skills and little experience of alternative view strategies, JSP is the obvious choice. If any team members come from a Microsoft ASP background, JSP will be likely to prove familiar. On the other hand, in a team with XSLT experience, XSLT might be preferred. If there is no JSP or XSLT experience among content developers, a simple template language such as Velocity may be the best choice, as it has a negligible learning curve.

Important 

Remember that page layout in all but very simple web applications will be maintained by HTML developers, not Java developers. Thus we must consider their skills and preferences when selecting view technology. Real J2EE development involves multi-disciplinary teams, not just Java developers.

Throughout this chapter we'll use one of the views from the sample application as an example. As we examine each view technology, we'll implement this view to provide a practical example.

We'll also look at the important concept of view composition: building complex pages through combining the outputs of other views or page components. View composition is an essential technique in building the complex pages required on real web sites. We'll examine two common approaches to view composition, with practical examples.

This chapter isn't intended as a guide to using each of the view technologies discussed, but as an overview of how to use each in MVC web applications and a high-level view of the strengths and weaknesses of each. Each section contains references to further information on the technology in question.

Although most of the examples use the MVC web application framework introduced in Chapter 12, the concepts discussed are relevant to all web applications, and especially those using Struts and other j MVC frameworks. This chapter concentrates on what you need to do in application code to use each of the view technologies discussed, with a minimum of framework-specific content. See Appendix A for more detailed information on how to install and configure each of these view technologies, and the implementation of the framework's built-in support for each.