ViewHelper Pattern

Context

The system creates presentation content, which requires processing of dynamic business data.

Problem

Presentation tier changes occur often and are difficult to develop and maintain when business data access logic and presentation formatting logic are interwoven. This makes the system less flexible, less reusable, and generally less resilient to change.

Intermingling the business and systems logic with the view processing reduces modularity and also provides a poor separation of roles among Web production and software development teams.

Forces

• Business data assimilation requirements are nontrivial.

§         Embedding business logic in the view promotes a copy-and-paste type of reuse. This causes maintenance problems and bugs because a piece of logic is reused in the same or different view by simply duplicating it in the new location.

§         It is desirable to promote a clean separation of labor by having different individuals fulfill the roles of software developer and Web production team member.

§         One view is commonly used to respond to a particular business request.

Solution

A view contains formatting code, delegating its processing responsibilities to its helper classes, implemented as JavaBeans or custom tags. Helpers also store the view's intermediate data model and serve as business data adapters.

There are multiple strategies for implementing the view component. The JSP View Strategy suggests using a JSP as the view component. This is the preferred strategy, and it is the one most commonly used. The other principal strategy is the Servlet View Strategy, which utilizes a servlet as the view (see the section "Strategies" for more information).

Encapsulating business logic in a helper instead of a view makes our application more modular and facilitates component reuse. Multiple clients, such as controllers and views, may leverage the same helper to retrieve and adapt similar model state for presentation in multiple ways. The only way to reuse logic embedded in a view is by copying and pasting it elsewhere. Furthermore, copy-and-paste duplication makes a system harder to maintain, since the same bug potentially needs to be corrected in multiple places.

A signal that one may need to apply this pattern to existing code is when scriptlet code dominates the JSP view. The overriding goal when applying this pattern, then, is the partitioning of business logic outside of the view. While some logic is best encapsulated within helper objects, other logic is better placed in a centralized component that sits in front of the views and the helpers-this might include logic that is common across multiple requests, such as authentication checks or logging services, for example. Refer to the "Intercepting Filter" on page 4 and "Front Controller" on page 21 for more information on these issues.

If a separate controller is not employed in the architecture, or is not used to handle all requests, then the view component becomes the initial contact point for handling some requests. For certain requests, particularly those involving minimal processing, this scenario works fine. Typically, this situation occurs for pages that are based on static information, such as the first of a set of pages that will be served to a user to gather some information (see "Dispatcher View" on page 232). Additionally, this scenario occurs in some cases when a mechanism is employed to create composite pages (see "Composite View" on page 203).

The View Helper pattern focuses on recommending ways to partition your application responsibilities. For related discussions about issues dealing with directing client requests directly to a view, please refer to the section "Dispatcher View" on page 232.

Structure

Figure 7.11 is the class diagram representing the View Helper pattern.

Figure 7.11 View Helper class diagram

Participants and Responsibilities

Figure 7.12 shows the sequence diagram representing the View Helper pattern. A controller typically mediates between the client and the view. In some cases, though, a controller is not used and the view becomes the initial contact point for handling the request. (Also, see Dispatcher View pattern.)

Figure 7.12 View Helper sequence diagram

As noted in the class diagram, there may be no helpers associated with a view. In this simple case, the page may be entirely static or include very small amounts of inline scriptlet code. This scenario is described in the sequence diagram in Figure 7.13.

Figure 7.13 View Helper simple sequence diagram

View

A view represents and displays information to the client. The information that is used in a dynamic display is retrieved from a model. Helpers support views by encapsulating and adapting a model for use in a display.

Helper

A helper is responsible for helping a view or controller complete its processing. Thus, helpers have numerous responsibilities, including gathering data required by the view and storing this intermediate model, in which case the helper is sometimes referred to as a value bean. Additionally, helpers may adapt this data model for use by the view. Helpers can service requests for data from the view by simply providing access to the raw data or by formatting the data as Web content.

A view may work with any number of helpers, which are typically implemented as JavaBeans (JSP 1.0+) and custom tags (JSP 1.1+). Additionally, a helper may represent a Command object, a delegate (see "Business Delegate" on page 248), or an XSL Transformer, which is used in combination with a stylesheet to adapt and convert the model into the appropriate form.

ValueBean

A value bean is another name for a helper that is responsible for holding intermediate model state for use by a view. A typical case, as shown in the sequence diagram in Figure 7.12, has the business service returning a value bean in response to a request. In this case, ValueBean fulfills the role of a Transfer Object (see "Transfer Object" on page 261).

BusinessService

The business service is a role that is fulfilled by the service the client is seeking to access. Typically, the business service is accessed via a Business delegate. The business delegate's role is to provide control and protection for the business service (see the "Business Delegate" on page 248).

Strategies

JSP View Strategy

The JSP View Strategy suggests using a JSP as the view component. This is the preferred strategy to the Servlet View Strategy. While it is semantically equivalent to the Servlet View Strategy, it is a more elegant solution and is more commonly used. Views are the domain of Web designers, who prefer markup to Java code. Example 7.17 shows a code sample for this strategy. The excerpt is from a source file called welcome.jsp, to which a servlet controller dispatches after placing the WelcomeHelper JavaBean in request scope.

Example 7.17 JSP View Strategy Sample Code

<jsp:useBean id="welcomeHelper" scope="request"   class="corepatterns.util.WelcomeHelper" />   <HTML> <BODY bgcolor="FFFFFF"> <% if (welcomeHelper.nameExists()) { %> <center><H3> Welcome <b> <jsp:getProperty name="welcomeHelper" property="name" /> </b><br><br> </H3></center> <% } %>   <H4><center>Glad you are visiting our   site!</center></H4>   </BODY> </HTML>

 

The alternative Servlet View Strategy is typically implemented by embedding HTML markup directly within Java Servlet code. Intermingling Java code and markup tags creates a poor separation of user roles within a 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 an 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 projects often start small-with simple requirements and few developers-but may ultimately evolve to become sophisticated enough to benefit from these suggestions.

Servlet View Strategy

The Servlet View Strategy utilizes a servlet as the view. It is semantically equivalent to the preferred JSP View Strategy. However, the Servlet View Strategy, as seen in Example 7.18, 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 modify.

Example 7.18 Servlet View Strategy Sample Code

public class Controller extends HttpServlet {   public void init(ServletConfig config) throws     ServletException {     super.init(config);   }     public void destroy() { }     /** Processes requests for both HTTP     * <code>GET</code> and <code>POST</code> methods.    * @param request servlet request    * @param response servlet response    */   protected void processRequest(HttpServletRequest     request, HttpServletResponse response)     throws ServletException, java.io.IOException {     String title = "Servlet View Strategy";     try {       response.setContentType("text/html");       java.io.PrintWriter out = response.getWriter();       out.println("<html><title>"+title+"</title>");       out.println("<body>");       out.println("<h2><center>Employees List</h2>");       EmployeeDelegate delegate =           new EmployeeDelegate();         /** ApplicationResources provides a simple API         * for retrieving constants and other            * preconfigured values**/       Iterator employees = delegate.getEmployees(             ApplicationResources.getInstance().                 getAllDepartments());       out.println("<table border=2>");       out.println("<tr><th>First Name</th>" +         "<th>Last Name</th>" +           "<th>Designation</th><th>Id</th></tr>");       while (employees.hasNext())                       {         out.println("<tr>");         EmployeeTO emp = (EmployeeTO)employees.next();         out.println("<td>"+emp.getFirstName()+             "</td>");         out.println("<td>"+emp.getLastName()+             "</td>");         out.println("<td>"+emp.getDesignation()+             "</td>");         out.println("<td>"+emp.getId()+"</td>");         out.println("</tr>"); }       out.println("</table>");       out.println("<br><br>");       out.println("</body>");       out.println("</html>");       out.close();     }     catch (Exception e) {       LogManager.logMessage("Handle this exception",         e.getMessage() );     }   }     /** Handles the HTTP <code>GET</code> method.     * @param request servlet request     * @param response servlet response     */   protected void doGet(HttpServletRequest request,     HttpServletResponse response)     throws ServletException, java.io.IOException {         processRequest(request, response);   }     /** Handles the HTTP <code>POST</code> method.     * @param request servlet request     * @param response servlet response     */   protected void doPost(HttpServletRequest request,     HttpServletResponse response)     throws ServletException, java.io.IOException {         processRequest(request, response);   }     /** Returns a short description of the servlet. */   public String getServletInfo() {     return "Example of Servlet View. " +               "JSP View is preferable.";   }     /** dispatcher method **/   protected void dispatch(HttpServletRequest request,       HttpServletResponse response, String page)   throws javax.servlet.ServletException,       java.io.IOException       {     RequestDispatcher dispatcher =       getServletContext().getRequestDispatcher(page);     dispatcher.forward(request, response);   } }

 

JavaBean Helper Strategy

The helper is implemented as a JavaBean. Using helpers results in a cleaner separation of the view from the business processing in an application, since business logic is factored out of the view and into the helper component. In this case the business logic is encapsulated in a JavaBean, which aids in content retrieval and adapts and stores the model for use by the view.

Using the JavaBean Helper Strategy requires less upfront work than does the Custom Tag Helper Strategy, since JavaBeans are more easily constructed and integrated into a JSP environment. Additionally, even novice developers understand JavaBeans. This strategy is also easier from a manageability standpoint, since the only resulting artifacts are the completed JavaBeans. An example of this strategy is shown in Example 7.19.

Example 7.19 JavaBean Helper Strategy Code Sample

<jsp:useBean id="welcomeHelper" scope="request"   class="corepatterns.util.WelcomeHelper" />   <HTML> <BODY bgcolor="FFFFFF"> <% if (welcomeHelper.nameExists()) { %> <center><H3> Welcome <b> <jsp:getProperty name="welcomeHelper" property="name" /> </b><br><br> </H3></center> <% } %>   <H4><center>Glad you are visiting our   site!</center></H4>   </BODY> </HTML>

 

Custom Tag Helper Strategy

The helper is implemented as a custom tag (JSP 1.1+ only). Using helpers results in a cleaner separation of the view from the business processing in an application, since business logic is factored out of the view and into the helper component. In this case the business logic is encapsulated in a custom tag component, which may aid in content retrieval and adapts the model for use by the view.

Using the Custom Tag Helper Strategy requires more upfront work than does the JavaBean Helper Strategy, since custom tag development is moderately complicated relative 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. To use this strategy, the environment must be configured with numerous generated artifacts, including the tag itself, a tag library descriptor, and configuration files. An excerpt of a JSP View using this strategy is shown in Example 7.20.

Example 7.20 Custom Tag Helper Strategy Sample Code

<%@ taglib uri="/web-INF/corepatternstaglibrary.tld"   prefix="corepatterns" %> <html> <head><title>Employee List</title></head> <body>   <div align="center"> <h3> List of employees in <corepatterns:department   attribute="id"/> department - Using Custom Tag   Helper Strategy. </h3> <table border="1" >     <tr>         <th> First Name </th>         <th> Last Name </th>         <th> Designation </th>         <th> Employee Id </th>         <th> Tax Deductibles </th>         <th> Performance Remarks </th>         <th> Yearly Salary</th>     </tr>     <corepatterns:employeelist id="employeelist_key">     <tr>         <td><corepatterns:employee             attribute="FirstName"/> </td>         <td><corepatterns:employee             attribute= "LastName"/></td>         <td><corepatterns:employee             attribute= "Designation"/> </td>         <td><corepatterns:employee             attribute= "Id"/></td>         <td><corepatterns:employee             attribute="NoOfDeductibles"/></td>         <td><corepatterns:employee             attribute="PerformanceRemarks"/></td>         <td><corepatterns:employee             attribute="YearlySalary"/></td>         <td>      </tr>     </corepatterns:employeelist> </table> </div> </body> </html>

 

Business Delegate as Helper Strategy

Helper components often make distributed invocations to the business tier. We suggest using a business delegate in order to hide the underlying implementation details of this request, such that the helper simply invokes a business service without knowing details about its physical implementation and distribution (see "Business Delegate" on page 248).

Both a helper and a business delegate may be implemented as a JavaBean. Thus, one could combine the notion of the helper component and the business delegate and implement the business delegate as a specialized type of helper. One major distinction between a helper and a business delegate, though, is as follows: A helper component is written by a developer working in the presentation tier, while the delegate is typically written by a developer working on the services in the business tier. (Note: The delegate may also be provided as part of a framework.) Thus, this strategy is as much about who actually writes the delegate as it is about the implementation. If there is some overlap in developer roles, then the business delegate as helper is a strategy to consider.

Example 7.21 Business Delegate as Helper Strategy Sample Code

/**A servlet delegates to a command object helper, as   shown in the following excerpt:**/ String resultPage = command.execute(request,   response);   /**The command object helper uses the business   delegate, which is simply implemented as another   JavaBean helper, as shown in the following excerpt:**/     AccountDelegate accountDelegate = new   AccountDelegate();

 

 

Transformer Helper Strategy

The helper is implemented as an eXtensible Stylesheet Language Transformer. This is particularly useful with models that exist as structured markup, such as eXtensible Markup Language (XML), either natively within legacy systems or via some form of conversion. 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.

Figure 7.16 describes a potential implementation of this strategy.

Figure 7.16 Sequence diagram for Transformer Helper Strategy

The controller handles the request and invokes a Command object, implemented as a JavaBean helper. The Command object initiates the retrieval of Account data. The Account object invokes the business service, which returns the data in the form of a Transfer Object (see "Transfer Object" on page 261), implemented as a JavaBean.

Content retrieval is complete and control is dispatched to the AccountView, which uses its custom tag transformer to manipulate the model state. The transformer relies on a stylesheet, which describes how to transform the model, typically describing how to format it with markup for display to the client. The stylesheet is usually retrieved as a static file, though it may also be dynamically generated.

An example of how the custom tag helper might look in AccountView follows:

<xsl:transform model="accounthelper"

 stylesheet="/transform/styles/basicaccount.xsl"/>

The integration of eXtensible Stylesheets and XML with JSP is evolving, as tag libraries in this area continue to mature. For now, it is a less preferred strategy, given the immature state of the supporting libraries and the additional sophisticated skills necessary to generate and maintain the stylesheets.

Consequences

• Improves Application Partitioning, Reuse, and Maintainability
  Using helpers results in a cleaner separation of the view from the business processing in an application. The helpers, in the form of JavaBeans (JSP 1.0+) and custom tags (JSP 1.1+), provide a place external to the view to encapsulate business logic. Otherwise, scriptlet code clutters the JSP, a cumbersome and unwieldy situation, especially in larger projects.

Additionally, business logic that is factored out of JSPs and into JavaBeans and custom tags is reused, reducing duplication and easing maintenance.

• Improves Role Separation
  Separating formatting logic from application business logic reduces dependencies that individuals fulfilling different roles might have on the same resources. For example, a software developer might own code that is embedded within HTML markup, while a Web production team member might need to modify page layout and design components that are intermingled with business logic. Neither individual fulfilling these roles may be familiar with the implementation specifics of the other individual's work, thus raising the likelihood of accidental modifications introducing bugs into the system.

Related Patterns

• Business Delegate
  The helper components need to access methods in the business service API. It is also important to reduce the coupling among helpers in the presentation tier and among business services in the business tier. It is recommended that a delegate be used because these tiers may be physically distributed across a network. The delegate hides from the client the underlying details of looking up and accessing the business services, and it may also provide intermediate caching to reduce network traffic.
• Dispatcher View and Service to Worker
  When centralized control becomes desirable to handle such issues as security, workflow management, content retrieval, and navigation, consider the Dispatcher View or Service to Worker patterns.
• Front Controller
  This pattern is paired with the View Helper pattern to create the Dispatcher View pattern or Service to Worker pattern.

 

Contact Us© 2001-2002 Sun Microsystems, Inc. All Rights Reserved.