Many pages in an application view have the some different content and also some common content. As a user browses through the pages, the data and content among the different pages varies, but many elements such as a common header or sidebar on each view remain the same. The structure and layout of each page may be the same on all the pages of the view. And some elements or sections of a page may appear on several different pages. When such elements and groups are coded directly into application views, views are difficult to modify and are likely to contain inconsistencies. In addition, a consistent look and feel for every application view is difficult to achieve, and more difficult to maintain, when coding views directly.

A Composite View is a view built using other reusable sub-views. A single change to a sub-view is automatically reflected in every composite view that uses it. Furthermore, the composite view manages the layout of its sub-views and can provide a template, making consistent look and feel feel easier to achieve and modify across the entire application.

See the Core J2EE Patterns

There are several strategies for applying the Composite View pattern. What all strategies have in common is that sub-views are defined separately, and are individually reusable.

The layout of a composite view in the Java Pet Store sample application is controlled by a Java ServerPages^TM (JSP^TM) page called template.jsp. The contents of a specific composite view are controlled by another file, screendefinitions.xml, that binds JSP pages to named areas of the template. The following code block shows an excerpt from the Java Pet Store sample application website screen definitions file that defines the "main" screen, binding JSP pages to named areas of the template:

        
  <screen name="main">
    <parameter key="banner" value="/banner.jsp" />
    <parameter key="sidebar" value="/sidebar.jsp" />
    <parameter key="body" value="/main.jsp" />
    <parameter key="footer" value="/footer.jsp" />
   </screen>

      

The example shown in Figure 1 is the screen that results from the definition above. Each page area is populated with data from a separate JSP page.

Figure 1. Multiple JSP pages form a composite view

The sample application controls composite view assembly using a centralized view manager called TemplateServlet . To create a composite view, the application developer first defines a template file, which controls the layout of the view. The developer uses template:insert tags at various points in the template file to include dynamically-generated content. (The insert tag is implemented by the Web Application Framework class InsertTag .)

The developer then creates a screen definitions file, which associates each insert tag with the URL of the sub-view to be included at that point. So the template controls the layout of the composite view, and the screen definition controls selects the group of sub-views to be included within the layout. Each screen definition selects a different set of sub-views, so the contents of each view may differ, while the layout of all views remains the same. Figure 2 below shows how the template servlet assembles a composite view.

Figure 2. Block diagram of composite view assembly

After servicing a client request, the Front Controller selects the next view to display and forwards the request to it. (In the figure, this view is /main.screen.) A servlet mapping routes the request to a TemplateServlet, which reads the screen definitions defined by the application developer, finds the appropriate screen, and stores the screen in an HttpSession attribute. The TemplateServlet then forwards the request to the template defined in the screen definitions file ( /template.jsp). The screen definition associates symbolic names with Web resources to be used as sub-views in the composite view. The example in the figure shows the tag <parameter key="banner" value="/banner.jsp"/>, which defines /banner.jsp as the content for the banner of the screen called main.

The template file contains the page layout, plus any text that appears on every page of the application. It also contains embedded template:insert tags, each of which indicates the name of a sub-view to be included in the response. For example,
<template:insert parameter="banner"/> inserts the banner page for the current screen at that point.

When the server executes the template page, each template:insert tag uses the screen (retrieved from HttpSession) to look up the URL of the content to include. In the example shown in Figure 2, the contents of /banner.jsp are inserted at the point in the template where the template:insert tag occurs. The page resulting from the execution of the template JSP page is served to the client as the HTTP response.

A more detailed sequence diagram of this process appears in Figure 2. Each item in the list following the figure describes the corresponding numbered transition in the diagram.

Figure 2. A sequence diagram of composite view assembly

• 1. The client requests service


• 2. After processing the request, MainServlet (the Front Controller) directs the ScreenFlowManager to select the next view


• 3. The ScreenFlowManager determines the name of the screen to display


• 4. The request is forwarded to TemplateServlet


• 5. The TemplateServlet identifies the requested Screen object and stores it in HttpSession


• 6. The request is forwarded to the template JSP page


• 7. The template JSP page executes an insert tag


• 8. The insert tag retrieves the screen from HttpSession


• 9. The insert tag inserts the content from the URL corresponding to the value of its parameter attribute


• 10 - 12. The template JSP page executes another insert tag, which inserts the content as in the steps 7 - 9.


• 13. Template execution is complete, and the server returns the generated response to the client.