J2EE DESIGN PATTERNS - Composite view

In real world application web pages present content from numerous data sources, using multiple subviews that comprise a single display page. The web pages are built by embedding formatting code directly with each atomic view. Atomic portion of the view content changes frequently , modification to the layout of multiple view is difficult and error prone when subviews are directly embedded and duplicated in multiple views. Embedding frequently changing portions of template text directly into views also potentially affects the availability and administration of the system. The server may need to be restarted before clients see the modifications or updates to these template components.

The solution to this is to use composite views that are composed of multiple atomic subviews. Each component of the template may be included dynamically into the whole and the layout of the page may be managed independently of the content. This solution provides for the creation of a composite view based on the inclusion and substitution of modular dynamic and static template fragments. It promotes the reuse of atomic portions of the view by encouraging modular design. It is appropriate to use a composite view to generate pages containing display components that may be combined in a variety of ways. The layout of the page is managed and modified independent of the subview content. Another benefit of this pattern is that Web designers can prototype the layout of a site, plugging static content into each of the template regions. As site development progresses, the actual content is substituted for these placeholders. The responsibilities of the components participating in this patterns are : Composite View : A composite view is a view that is an aggregate of multiple subviews. View Manager : 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 page runtime engine, in the form of the standard JavaServer Pages (JSP page) pages include tag (<jsp:include>), or it may be encapsulated in a JavaBean helper (JSP page 1.0+) or custom tag helper (JSP page 1.1+) to provide more robust functionality. 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. Included View 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. Composite view improves modularity and reuse. 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 type of dynamic layout and composition reduces duplication, fosters reuse, and improves maintainability. Composite view enhances flexibility. A sophisticated implementation may conditionally include view template fragments based on runtime decisions, such as user role or security policy. Composite view enhances maintainability and 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 template content independent of the template layout. Additionally, these changes are available to the client immediately, depending on the implementation strategy. Modifications to the layout of a page are more easily managed as well, since changes are centralized. Composite view reduces manageability. Aggregating atomic pieces of the display together to create a single view introduces the potential for display errors, since subviews are page fragments. This is a limitation that can become a manageability issue. For example, if a JSP page 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 (that is, <HTML> and </HTML>), then the composed page will be invalid. Thus, it is important when using this pattern to be aware that subviews must not be complete views. Tag usage must be accounted for quite strictly in order to create valid composite views, and this can become a manageability issue. But Composite view has 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, though typically extremely minimal, 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.