Sun Java Center J2EE Patterns

Print-friendly Version

Composite View

Context

System handles web requests. Presentation processing requires generating a view based on a template and dynamic model.

Problem

Instead of providing a mechanism to combine modular, atomic portions of a view into a composite whole, pages are built by embedded formatting code directly within each View.

Modifications to the layout of a View are difficult and prone to errors, due to the duplication of code.

Forces

• Atomic portions of the View content change frequently, as in the case of a portal site.
• Multiple composite views are desirable using similar atomic portions, such as a customer inventory table. These atomic portions are decorated with different surrounding template text or they appear in a different location within the page.
• Changing the layout of a View can be difficult when subviews are directly embedded and duplicated in each View.
• Embedding frequently changing parts of the template directly into the view also potentially affects the availability and administration of the system, since the server may need to be restarted to modify or update these template components.

Solution

Use composite views that are aggregates of multiple atomic template components that can be included dynamically into the whole.

This solution provides for the creation of a composite view based on the inclusion and substitution of modular dynamic and static template fragments. This solution also promotes the reuse of atomic portions of the View, and encourages modular design. It is appropriate to use a composite view to generate displays containing pluggable atomic components that may be combined in a variety of ways. This scenario occurs, for example with portal sites that include numerous independent views, such as news feeds, weather information, and stock quotes on a single page. There may be a runtime overhead associated with this pattern, and it is the tradeoff for the pattern's improved flexibility.

A system typically has many views, some of which rely on similar atomic pieces of the display to be presented in alternate ways, such as in different locations on the screen or containing modified text. An example is a customer inventory table that is used on multiple pages, surrounded by different information on each page. Another example, is a page that includes a header and footer. If each atomic subcomponent is coded directly into the main view in which it is included, the result is duplicate code that is difficult to modify and maintain.

When a component piece is coded directly into the view in which it is used, a change to that subcomponent requires changing each view that contains the subcomponent, requiring multiple modifications to make, in effect, a single change.

Structure

The following class diagram represents the Composite View pattern:

Participants & Responsibilities

The following sequence diagram represents the Composite View pattern:

A Composite View is a View that is an aggregate of multiple subviews.

The View Manager manages the inclusion of portions of template fragments into the Composite View. The View Manager may be part of a standard JSP^TM runtime engine, in the form of the standard JSP include tag (<jsp:include>) or it may be encapsulated in a JavaBean^TM Helper (JSP 1.0) or Custom Tag (JSP 1.1+) to provide more robust functionality. Additionally, the View Manager may be implemented as an eXtensible Stylesheet Transformer (XSLT).

A benefit of using a mechanism other than the standard include tag is that conditional inclusion is easily done. For example, certain template fragments may be included only if the user fulfills a particular role or certain system conditions are satisfied. Furthermore, using a Helper component as a View Manager allows for more sophisticated control of the page structure as a whole, which is useful for creating reusable page layouts.

An Included View is a subview that is one atomic piece of a larger whole View. This included view could also potentially be a composite, itself including multiple subviews.

Strategies

JSP View Strategy

The JSPView Strategy suggests using a JSP as the view component. This is the preferred strategy to the ServletView Strategy. While it is semantically equivalent to the Servlet View Strategy, it is a more elegant solution and is more commonly used.

Servlet View Strategy

The ServletView Strategy utilizes a servlet as the view. It is semantically equivalent to the preferred JSPView Strategy. However, the ServletView Strategy is often more cumbersome for the software development and web production teams because it embeds markup tags directly within the Java code. When tags are embedded within the code, the view template is more difficult to update and to modify. Additionally, intermingling Java code and markup tags creates a poor separation of user roles within the project and increases the dependencies on the same resources among multiple members of different teams. When an individual works on a template containing unfamiliar code or tags, it increases the likelihood of accidental change introducing problems into the system. There is also a reduction in work environment efficiency (too many people sharing the same physical resource) and an increase in source control management complexity.

These problems are more likely to occur in larger enterprise environments that have more complicated system requirements and that use teams of developers. They are less likely to occur with small systems that have simple business requirements and use few developers, because the same individual may likely fill the roles mentioned above. However, keep in mind that often projects start small-with simple requirements and few developers but often ultimately evolve to become sophisticated enough to benefit from these suggestions.

JavaBean View Manager Strategy

View Manager is implemented as a JavaBean. The View uses the JavaBean, which implements the custom logic to control the View Management decisions relating to what elements will make up the page. These decisions on what to substitute and include may be based on roles or policies, making it much more powerful than the standard Servlet/JSP include functionality. While it is semantically equivalent to the 'Custom Tag View Manager Strategy', it is not as elegant since it introduces some scriptlet code into the View.

Using the 'JavaBean View Manager Strategy' requires less up-front work than using the 'Custom View Manager Strategy', since it is easier to construct JavaBeans and integrate them into a JSP environment. Additionally, even the most novice developers understand JavaBeans. This strategy is also easier from a manageability standpoint, because the completed JavaBeans are the only resulting artifacts to manage and configure.

Custom Tag View Manager Strategy

View Manager is implemented as Custom Tag (JSP 1.1+). Logic implemented within the tag controls the View Management decisions relating to what elements will make up the page. These tags extend the behavior of the standard JSP include action and are much more powerful. These custom actions are able to base their decisions for doing page composition on such things as user roles or security policies.

Using the 'Custom Tag View Manager Strategy' requires more up-front work than does the 'JavaBean View Manager Strategy', since custom tag development is moderately complicated compared to JavaBean development. Not only is there more complexity in the development process, but there is much more complexity with respect to integrating and managing the completed tags. Using this strategy requires the generation of numerous artifacts, including the tag itself, a tag library descriptor, and configuration files, and configuring the environment with these artifacts.

Transformer View Manager Strategy

View Manager is implemented as an XSL Transformer.

When combined with other view manager strategies, the page can be built from numerous template fragments. These fragments themselves can be built based on stylesheets that are also composites, with larger stylesheets including and importing smaller stylesheets. Using this strategy can help to enforce the separation of the model from the view, since much of the view markup must be factored into a separate stylesheet.

Early-Binding Static Resource Strategy

The premise of this strategy is to include a piece of a template at translation time, as can be done with the standard JSP include directive.

The Early-Binding Static Resource Strategy provides flexibility for maintaining and updating a relatively static template. Its use is recommended if a view includes headers and footers that change infrequently.

Late-Binding Static Resource Strategy

The premise of this strategy is to include a piece of a template at runtime, as can be done with the standard JSP include action.

The Late-Binding Static Resource Strategy, which is an alternative to the Early-Binding Static Resource Strategy, is best used when aspects of the template change frequently or the template changes based on user activity. When using this strategy, a header may be included at runtime to allow up-to-the minute changes to appear in the display. Moreover, runtime inclusion as part of this strategy may be done in a policy-based manner. This means that inclusion of certain portions of a template might be based on such criteria as a user role or an access control list.

Late-Binding Dynamic Resource Strategy

The Late-Binding Dynamic Resource Strategy is semantically equivalent to recursively applying the composite view pattern, since a dynamic resource that is included as a portion of a particular display may also be a composite view. Performance issues may arise when using this strategy, since runtime inclusion has overhead costs associated with it. An example of this strategy is as follows:

Assume we have composite pages of the following structure:

Outer.jsp is composed of:

• OuterHeader.jsp
• OuterBody.jsp
• OuterFooter.jsp

OuterHeader.jsp is composed of:

• OuterHeader_Header.jsp
• OuterHeader_Body.jsp
• OuterHeader_Footer.jsp

OuterBody.jsp is composed of:

• InnerBody.jsp

InnerBody.jsp is composed of:

• InnerBodyHeader.jsp
• InnerBody_Body.jsp
• InnerBody_Footer.jsp

When we display Outer.jsp, we will be dynamically compiling, if necessary, and including all the dynamic resources that make up this page. One needs to consider the performance impacts of such a structure in light of project requirements.

Consequences

• Variable levels of sophistication for View Management
  The View Manager may be very basic, only utilizing the standard JSP include tag. Or it may be more sophisticated and be implemented as a JavaBean (JSP 1.0) or Custom Tag (JSP 1.1+). Additionally, the View Manager could be an XSL Transformer, and could even compose the stylesheet based on multiple files (see: xsl import and include).
• Role or Policy-based Decision
  A sophisticated View Manager implementation could conditionally include view template fragments based on runtime decisions, such as user role or system conditions.
• Improved Reusability
  The pattern promotes modular design. It is possible to reuse atomic portions of a template, such as a table of stock quotes, in numerous Views and to decorate these reused portions with different information. This pattern permits the table to be moved into its own module and simply included where necessary. This reduces duplication, fosters reuse, and improves maintainability.
• Enhanced Manageability
  It is much more efficient to manage changes to portions of a template when the template is not hardcoded directly into the View markup. When kept separate from the View, it is possible to modify modular portions of the template independent of the main template and to automatically include the changes, depending on the implementation strategy. Additionally, modifications to the layout of a page are more easily managed, due to its modular decomposition.
• Manageability problems
  Aggregating atomic pieces of the display together to create a single view introduces the potential for display errors. This is a limitation that can become a manageability issue. For example, if a JSP page is generating an HTML page using a main page that includes three subviews, and the subviews each include the HTML open and close tag (for example, <HTML> and </HTML>), then the composed page will be invalid. Thus, it is important when using this pattern to be aware that included portions of a view may not simply be other complete views. Tag usage must be accounted for quite strictly, in order to create valid composite views, and this can become a manageability issue.
• Performance Impact
  Generating a display that includes numerous subviews may slow performance. Runtime inclusion of subviews will result in a delay each time the page is served to the client. In an environment with strict Service Level Agreements that mandate specific response times, such performance slowdowns may not be acceptable. An alternative is to move the subview inclusion to translation time, though this limits the subview to changing when the page is retranslated.

Related Patterns

• View Helper Pattern [SJC]
  The Composite View pattern may be used as the View in the View Helper pattern.
• Composite Pattern [GoF]
  The Composite View pattern is based on the Composite pattern, which describes part-whole hierarchies where a composite object is comprised of numerous pieces, all of which are treated as logically equivalent.