What is Tiles | Struts Survival Guide: Basics to Best Practices (J2ee Survival Series)

Consider a banking application whose current web page layout has a header, body and footer as shown by the first layout in Figure 7.1. The management recently decided that all pages in the application should confirm to the corporate look and feel as shown in the second layout in Figure 7.1. The new layout has a header, footer, a varying body and a navigation sidebar.

Figure 7.1: Current and Future page layout for the banking application

When the application was first designed, the development team had two alternatives.

Use ‚“JSP based ‚½ approach. In this approach each JSP page is coded separately. Although the header and footer are common to every page, the common JSP markup for header and footer was added into each JSP by direct copy and paste. This quick and dirty solution is unacceptable even for the smallest of the web applications and poses a maintenance hurdle . Anytime the header and footer changes, it has to be manually applied to every page. Further, any changes to the page layout will have to be made in every page.
Use < jsp:include > approach. This approach is better than the previous one since it avoids repetition of common markup. The common markup related to header and footer is moved into JSPs of their own. The header and footer JSPs are added to the main JSP by using the standard < jsp:include > directive. Whenever header or footer changes, it affects only one or two files. However, if at any point in time, the layout of the pages itself changes (as it has happened for the banking application now), every JSP page with this structure has to be updated accordingly .

The team chose the second option at the time of development. However the new management directive is now posing a challenge. It is a tedious task to change every page of the system and there are chances that the current system might break in the process. Had they had Tiles framework at their disposal at the time of development, this change would have been a breeze !

Figure 7.2: Current Customer Details Page for My Bank

Figure 7.2 shows a sample HTML page from the banking application. Listing 7.1 shows the (simplified) JSP for that page. The JSP contains the < jsp:include > for the common header and footer, but has the entire layout written in terms of html table with various tr and td . All JSPs in the application also might have the same layout copied over and over. This is ‚“copy and paste technology ‚½ taken to the next dimension and exactly where Tiles comes into picture.

Listing 7.1: CustomerDetail JSP using <jsp:include>

 <%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %> <html:html locale="true"> <head>   <html:base/>   <title><bean:message key="title.customerform"/></title> </head> <body> <TABLE border="0" width="100%" cellspacing="5">   <tr><td><jsp:include page="/common/header.jsp"/></td></tr>   <tr>     <td>       <html:form action="/submitCustomerForm">       <table>         <tr>           <td>             <bean:message key="prompt.customer.firstname"/>           </td>           <td><html:input property="firstName"/></td>         <tr>         <tr>           <td>             <bean:message key="prompt.customer.lastname"/>           </td>           <td><html:input property="lastName"/></td>         <tr>         <tr>           <td><html:submit>Save Me</html:submit></td>           <td><html:cancel>Cancel</html:cancel></td>         <tr>       </table>     </td>   </tr>   <tr><td><hr></td></tr>   <tr><td><jsp:include page="/common/footer.jsp"/></td></tr> </TABLE> </body> </html:html>

The basic principle behind Tiles is to refactor the common layout out of the individual JSPs to a higher level and then reuse it across JSPs.

If the management wants a new look and feel, so be it; you can change the common layout JSP and the whole web application has the new look and feel! Redundancy is out and Reuse is in. In OO parlance this is similar to refactoring common functions from a set of classes into their parent class.

In Tiles, layouts represent the structure of the entire page. Layout is simply a JSP. Think of it as a template with placeholders (or slots). You can place other JSPs in these slots declaratively . For instance, you can create a layout with slots for header, body and footer. In a separate XML file (called XML tile definition file), you specify what JSPs go into these slots. At runtime, Tiles framework composes the aggregate page by using the layout JSP and filling its slots with individual JSPs.

In essence, Tiles is a document assembly framework that builds on the "include" feature provided by the JSP specification for assembling presentation pages from component parts . Each part (also called a tile, which is also a JSP) can be reused as often as needed throughout the application. This reduces the amount of markup that needs to be maintained and makes it easier to change the look and feel of a website. Tiles framework uses a custom tag library to implement the templates.

Comparing this approach with < jsp:include > will help you to understand the Tiles better. In the < jsp:include > approach, all included JSPs (header, footer etc.) become part of the core JSP before being rendered. In Tiles, all the JSPs ‚ header, footer and the core become part of the Layout JSP before being rendered. The outermost JSP rendered to the user is always the same; it is the layout JSP. This approach reduces redundancy of HTML and makes maximum reuse of formatting logic. The entire chapter deals with using Tiles for effective design in conjunction with Struts. In the next section, you will see how the banking application can be converted into a Tiles oriented design.