View Implementations

The following UML class diagram shows the view implementations discussed in this appendix, and how all are derived from the AbstractView convenience base class. The two classes at the bottom right illustrate how application-specific classes (in this case, classes from our sample application) extend the abstract framework superclasses for XMLC and PDF views:

The following framework view implementations are concrete, and can be used without subclassing:

• com.interface21.web.servlet.view.InternalResourceView
  View implementation that can expose model data using JSP, servlet, or other content within the current web application

• com.interface21.web.servlet.view.xslt.XsltView
  View implementation that can expose data using an XSLT stylesheet, converting JavaBeans in the model to XML form if necessary

• com.interface21.web.servlet.view.velocity. VelocityView
  View implementation that can expose data using a cached Velocity template

The following two classes are abstract superclasses for application-specific views. The two view technologies concerned require a Java class to be implemented for each view:

• com.interface21.web.servlet.view.xmlc.AbstractXmlcView
  Abstract superclass for views using XMLC technology. A static HTML template is used at run time, but the application-specific Java class holds page layout at run time.

• com.interface21.web.servlet.view.pdf.AbstractPdfView
  Abstract superclass for views using the iText library to generate PDF. No templates are involved, as all content is generated in Java code.

The View interface is simple to implement from scratch, but the com.interface21.web.servlet.view.AbstractView superclass provides a convenient superclass for most view implementations, using the Template Method design pattern to conceal the merging of static attributes with model objects supplied by the controller (if a static attribute and a model attribute share the same name, the model attribute will take precedence). Subclasses of AbstractView need to implement the following protected method, which has the same contract as the render ( ) method from the View interface, but works with a merged map of model and static attributes:

    protected abstract void renderMergedOutputModel (        Map model,        HttpServletRequest request,        HttpServletResponse response)        throws ServletException, IOException; 

AbstractView invokes this method in a final implementation of the render() method as follows. Note that dynamic (model) attribute values will replace static attributes with the same name:

    public final void render (Map pModel,         HttpServletRequest request, HttpServletResponse response)         throws ServletException, IOException {      // Consolidate static and dynamic model attributes      Map model = new HashMap (this . staticAttributes) ;      model.putAll (pModel) ;

     renderMergedOutputModel (model, request, response);

   } 

The AbstractView class exposes the following bean properties, inherited by all the view implementations discussed here: