Chapter 7: Tiles

---

Overview

Two of the foremost principles that underpin the Struts framework are the separation of concerns and reuse. These principles can be seen at work throughout the framework. For example, the separation of business logic into a Model layer applies separation of concerns, and the use of a configuration file for declarative coupling of components applies reuse. These principles are not, however, unique to the server side (Model and Controller) of applications.

Client-side (View) development has also been evolving to support the principles of separation of concerns and reuse. For example, cascading style sheets (CSS) allows common style elements to be defined in an external file that can be sourced in (that is, its contents included) by several pages. That way, each page does not have to define the same styles over and over. Instead, the pages simply use the common definitions defined in a style sheet. If a style needs to be changed, that change can be made in one file rather than in each page individually. This reduces the amount of time and overhead needed to make global changes, and reduces errors. This is the essence of reuse.

JSP technology supports a similar feature for reuse called includes. JSP includes allow other files (JSPs or otherwise) to be sourced in to a JSP, either at compile time or dynamically at run time. This feature is useful for abstracting common sections of pages, such as headers, footers, and menus, into reusable chunks that can be used by several files. If a change needs to be made to a common section, the change can be made once and each of the pages that includes that section will automatically receive the updates.

JSP includes offer both convenience and time savings. They are, however, somewhat limited insofar as the potential for a great deal of duplication still exists. Each JSP that sources in common sections duplicates the include definitions. If the name of one or more files being included change, each of the files including them would have to be updated. For example, assume that you have a set of JSPs called a.jsp, b.jsp, c.jsp, and d.jsp that all include header.jsp. If you rename header.jsp to mainHeader.jsp, then you would have to update a.jsp, b.jsp, c.jsp, and d.jsp to include mainHeader.jsp instead of header.jsp. This can be tedious, time consuming, and error prone. To solve this problem, and to enhance Struts, Cedric Dumoulin created the Tiles framework as a third-party add-on to Struts. Tiles has since been integrated into the core Struts code base and is now packaged with Struts as of version 1.1.

Tiles expands the concept of reuse via includes by allowing you to define layouts (or templates) and then specify how the layouts are populated with content. To understand the value of Tiles, first consider how the JSP include paradigm works. Each JSP specifies its layout and explicitly populates that layout through includes. Most JSP layouts are identical, sourcing in the same files in the same places and then having a section of unique content, which is usually body content. Thus, there is significant duplication. Tiles takes the reverse approach.

With Tiles, you define a master layout JSP that specifies each of the includes that fill in the layout and then you define which content should fill in the layout in an external configuration file. The same layout can be used over and over by simply specifying different filler content for the layout in the configuration file.

For example, consider a typical Web site layout that has a header at the top of the page, a menu on the left, body content in the middle, and a footer on the bottom, as shown in Figure 7-1. If you were to implement this page using only JSP includes, each JSP that has this layout would have to explicitly include the header, menu, and footer sections of the page, and the body content would be in the JSP itself. Essentially, the only unique part of the page is the body content.

Figure 7-1: Typical Web site layout

Alternatively, if you were to implement this layout with Tiles, you'd create one JSP that includes the header, menu, and footer and then dynamically include the body based on a parameter passed to the layout that indicates which JSP to use for the body content. This Tiles layout could then be reused for as many pages as you'd like and the only thing your content JSPs would have to contain is the body content that goes in the middle of the page. Tiles takes care of wrapping the body content JSP with the layout. As you can see, Tiles significantly enhances JSP development and allows for an even greater amount of reuse than JSP includes offer.

---