JaVa
   

Views in the Web Tier

Overview

In the last chapter we focused on how web apps should handle control flow and access business objects. In this chapter, we'll look closely at view technologies for J2EE web apps. The choice of view technologies can - and should - be largely independent of web app 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 apps. 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 apps 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:

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 , 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 app code. The deciding factors are likely to be:

Important 

Remember that page layout in all but very simple web apps 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 app 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 apps 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 app framework introduced in , the concepts discussed are relevant to all web apps, and especially those using Struts and other j MVC frameworks. This chapter concentrates on what you need to do in app 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.

JaVa
   
Comments