Composite View Design Pattern – Core J2EE Patterns

Among the core J2EE design patterns, the Composite View Design Pattern is known to compel the developers the most. The Composite View Pattern is responsible for building composite views from more than one sub views. The composite view pattern allows the content and layout to be plugged into the framework. This largely simplifies the development of the application.

Composite View Design Pattern

In the time, when the composite view was not known on a broader level, it was referred to as JSP templates. These templates combine the idea of composite and strategy patterns- in order to separate the content and layout from JSPs. The separation of this kind defines a unique JSP programming style, which allows the authors of the page and developers of the software to work independently, at least for most of the part.

Spring 5 Design Pattern Book

You could purchase my Spring 5 book that is with title name “Spring 5 Design Patterns“. This book is available on the Amazon and Packt publisher website. Learn various design patterns and best practices in Spring 5 and use them to solve common design problems. You could use author discount to purchase this book by using code- “AUTHDIS40“.

In almost all the modern object-oriented programming environments, three key objects are supported in order to create an extensible and flexible graphical user interface (GUI) development. These objects are; containers, layout managers, and components. The components basically represent the graphic objects like buttons, lists, or texts. The container object is responsible for maintaining the components lists. The layout managers are responsible for managing the size and position (or layout) of the components in the container.

Class Diagram for Composite View Pattern

Let’s see the following class diagram illustrates about the composite view design pattern.

Use Composite Views that are composed of multiple atomic subviews. Each subview of the overall template can be included dynamically in the whole, and the layout of the page can be managed independently of the content.

Implementation

The developers generally, implement the components and containers with the GoF’s composite design patterns. It allows them to form tree hierarchies by composing the graphical objects. The layout managers are generally implemented with the gang of four strategy design pattern. This allows the developer to be able to change the layout strategy of a container without having to change the container itself. Certain composite views use somewhat alike sub views, for example, a customer inventory table. These atomic portions are adorned with several template texts all through the page. When the subviews are directly embedded and duplicated in multiple views, it is more difficult manage the layout alterations and harder to maintain the code.

The accessibility and administration of the system are significantly affected when the chronically altering portions of template texts are embedded into the views. There might be a need to restart the servers before the clients are able to notice the updates and modifications which are made to these template components. The composite view patterns cater different responsibilities and give certain advantages to the developers. It improves the modularity and the reusability while enhancing the flexibility. It also enhances the maintainability and manageability.

Composite View Pattern using Apache tile view resolver

In web application, the View is one of the most important component. Developing this component is not so easy as seems that. It will be very complicated some to maintain and it will be a daunting task. Whenever we creates the view for the web application and always focus on the re-usability of the view components. We can define some static templates that can be reused in the other view pages inn the same web application. According to the Composite Design pattern of GOF pattern, we are composing the sub view components for a particular view component. The Composite View Pattern promotes the re-usability of views and easy to maintain due to the multiple sub views instead of creating a large and complicated view.

@Configuration
@EnableWebMvc
public class SpringMvcConfig extends WebMvcConfigurerAdapter{
	.....
	@Bean
	public TilesConfigurer tilesConfigurer() {
		TilesConfigurer tiles = new TilesConfigurer();
		tiles.setDefinitions(new String[] {
			"/WEB-INF/layout/tiles.xml"
		});
		tiles.setCheckRefresh(true);
		return tiles;
	}
	
	@Bean
	public ViewResolver viewResolver() {
		return new TilesViewResolver();
	}
	...
}

As you can see in the above configuration file, I have configured two beans TilesConfigurer and TilesViewResolver bean. First bean TilesConfigurer has responsibility to locate and load tile definitions and generally coordinate Tiles. And Second bean TilesViewResolver is responsible to resolve logical view names to tile definitions.

    
<tiles-definitions>
 <definition name="base.definition" template="/WEB-INF/views/mainTemplate.jsp">
 <put-attribute name="title" value=""/>
 <put-attribute name="header" value="/WEB-INF/views/header.jsp"/>
 <put-attribute name="menu" value="/WEB-INF/views/menu.jsp"/>
 <put-attribute name="body" value=""/>
 <put-attribute name="footer" value="/WEB-INF/views/footer.jsp"/>
 </definition>
 
 <definition extends="base.definition" name="openAccountForm">
 <put-attribute name="title" value="Account Open Form"/>
 <put-attribute name="body" value="/WEB-INF/views/accountForm.jsp"/>
 </definition>
 
 <definition extends="base.definition" name="accountsList">
 <put-attribute name="title" value="Employees List"/>
 <put-attribute name="body" value="/WEB-INF/views/accounts.jsp"/>
 </definition>
 ...
 ...
</tiles-definitions>        

As you can see in the above code, <tiles-definitions> element has multiple <definition> elements. And each element defines a tile and each tile references to a JSP template. And some elements extend the base tile definition because base tile definition has the common layout the all views in the web application.

Let’s see the base definition template the that is mainTemplate.jsp.

  
<%@ taglib uri="http://www.springframework.org/tags" prefix="s" %>
<%@ taglib uri="http://tiles.apache.org/tags-tiles" prefix="t" %>
<%@ page session="false" %>
<html> 
 <head> 
 <title>
 <tiles:insertAttribute name=”title” ignore=”true”/>
 </title>
 </head>
 <body>
 <table border=”1″ cellpadding=”2″ cellspacing=”2″ align=”left”>
 <tr>
 <td colspan=”2″ align=”center”>
 <tiles:insertAttribute name=”header”/>
 </td>
 </tr>
 <tr>
 <td>
 <tiles:insertAttribute name=”menu”/>
 </td>
 <td>
 <tiles:insertAttribute name=”body”/>
 </td>
 </tr>
 <tr>
 <td colspan=”2″ align=”center”>
 <tiles:insertAttribute name=”footer”/>
 </td>
 </tr>
 </table>
 </body> 
</html>

As in the above JSP file, I have used the <tiles:insertAttribute> JSP tag from the Tiles tag library to insert other templates.