In case you haven’t heard, the Apache Tiles framework, which gained popularity and widespread adoption as a Struts plugin, graduated into its own top-level Apache project in late 2006. The Apache Tiles project is now responsible for releasing and maintaining Tiles2, the next generation of the framework. As of this writing, Tiles 2.0.4 has been released as a beta quality release and several organizations have reported successful production deployments. A “General Availability” (GA) release should follow quickly.
Most developers familiar with the original Struts-Tiles framework (the one bundled with the popular Struts 1.1) will find very few differences between using Tiles 2.0.x and previous releases. In fact, the primary goal of the 2.0.x release series was to remove Struts dependencies and simplify its integration with other web frameworks. To most developers, these are architectural issues that will have little effect during deployment. Additionally, deprecated tags have been removed and several others have been renamed or tweaked to clarify their usage. Beyond the architectural and cosmetic changes to Tiles2, there is one enhancement that may alone make upgrading worth while—The “TilesDecorationFilter.”
Perhaps the biggest issue with the original versions of Tiles was the configuration burden that it imposed. Prior to Tiles2, many deployments required either a unique “configuration” or XML configuration for every unique request. In many cases where tiles was being used for applying a consistant look and feel throughout a site, this resulted in significant duplication. In fact, in most cases, each definition was nearly identical—differing only by the fact that the configured tiles included a different JSP that would provide the page “content.” The TilesDecortationFilter provides a standard mechanism for solving this problem.
The TilesDecorationFilter provides auto-configuration of tiles definitions. To use it, simply configure your filter to intercept any request to which you’d like to provide a standard look and feel. The filter will intercept the request, create a new templating definition that includes the standard set of tiles, configure the content page dynamically based on the original request, and render the definition. In many cases, the use of the decoration filter reduces the amount of XML configuration from one tiles definition per unique request to a single definition. This single definition then is applied to all requests.
The following example shows how to easily provide a standard look and feel in a web application using a MVC type web framework. In most cases, these applications dispatch to their render lifecycle by forwarding the request to a JSP. The filter configuration below will intercept all JSP requests that are forwarded to, configure the tiles definition called “standard” with an attribute called “body,” and invoke that definition.
Figure 1: TilesDecorationFilter Definition
Figure 2: Filter Mapping
Using the TilesDecorationFilter can significantly reduce the amount of configuration in your web application. If you are looking for a templating engine that will provide a standard look and feel with minimal configuration, Tiles2 may well be your solution.
About the Author
David DeWolf is the chief technical architect and founder of Three Pillar Software, Inc. He works with mid-sized and Fortune 1000 companies to establish corporate standards that promote best practices and agile development. David has over eight years of commercial software development experience and is a member of the Apache Software Foundation’s Struts, Tiles, and Portals projects. David actively participates in the Java Community Process as a member of the Java Portlet Specification Expert Group and is the author of various online publications.
