View Objects and Models

In the previous chapter you read a short discussion on the Model-View-Controller paradigm. In the MVC triad, a view is responsible for rendering the model prepared by the controller. Also, through the view, users might be able to execute further actions — for example, by clicking a link. Because achieving view independence is one of the major requirements we've set for Spring, controllers don't know what view will be rendered. This is a Good Thing, as it allows controllers to be reused with different view technologies if necessary — and it often is necessary in complex applications. Controllers indicate only a logical view name; the framework takes further responsibility to resolve the JSP or Velocity template in question and renders it.

Important 

Keep in mind that a view is just rendering the model. It should access the model only in read-only fashion. In other words, avoid calling setters. In addition, you should avoid calling methods that throw exceptions — the last thing you want to do is debug your JSP to look for a potential method call that throws an exception. Related to that, avoid using try-catch blocks (either using inline Java code or by using the JSTL tags). They make code unreadable to HTML programmers and it often results in situations where exceptions get silently swallowed.

The Open Session in View pattern (see Chapter 7) creates a situation where exceptions can be thrown all over the place. Carefully assess the situation to see if you really need this construct. It lengthens the lifetime of your session, causing more (maybe unnecessary) resources to be consumed, but it can also result in error-prone situations. Do not forget to set up a proper error handling mechanism in web.xml using error pages or the like — once the view has started rendering, Spring has handed off control, so HandlerExceptionResolvers won't suffice.

Views render models, so must have access to them. The way views access model data isn't the same across all view technologies. JSPs use data in the HTTP request context along with session- or application- scoped data. Velocity, on the other hand, doesn't have the notion of application-scoped data. In fact, it doesn't even rely on HTTP-specific constructs to access the model. This is one of the main reasons that models in Spring Web MVC are plain and simple instances of java.util.Map. Tying a view technology to transport-specific constructs, such as HTTP request context, should ideally always be avoided if possible. A graphical layout of the preparation of the view is displayed in Figure 13-2.

Figure 13-2

In the case of a JavaServer Page or a Velocity template, the template file embodies the actual markup of what should be rendered to the client. In the case of an Excel file (which is just as much a view on model data as a JSP is), we will need to write a Java class implementing the logic to create and output the spreadsheet. That said, we can distinguish between preparing the model so that the logic rendering the response (be it a JSP file or a piece of Java code creating rows and cells in an Excel file) will be able to access it, and the actual rendering of the response to the client. In the case of the Excel file, both the preparation of the model as well as the actual rendering is done by Java code. In the case of a JSP, a view object (Java code) prepares the request context — merges the model into it — and the JSP file renders it.

We've seen that all views in Spring Web MVC are implemented by a View object, all having a render(Map, HttpServletRequest, HttpServletResponse) method. As we continue, we will review the most common view technologies used in applications built with Spring Web MVC and we'll see how to use, among others, the AbstractExcelView, the JstlView, as well as the Tiles Configurer and corresponding TilesView. We will also cover how to use some of the macros and custom tags Spring comes with and how to use tag files and JSP fragments to simplify the creation of forms.