Your first Tiles application | Struts Survival Guide: Basics to Best Practices (J2ee Survival Series)

In this section, you will learn how to assemble a Tiles application. We will start with the CustomerDetails.jsp in Listing 7.1 and change it to use Tiles. The Customer Details page is first shown to the user . When the submit button in the Customer Form is pressed, a Success page is shown. Note that we are not referring to ‚“ .jsp ‚½ files any more. Instead they are being referred to as ‚“pages ‚½. There is a reason for this. Strictly speaking, the only JSP file that the user gets every time is the Layout JSP ‚ the aggregate page. Hence the several incarnations of Layout.jsp that the user sees are distinguished by their core contents ‚ Customer Details information, Success information and so on.

Step 1: Creating the Layout

To start with, let us concentrate on Tiles enabling the Customer Details Page. The first step is to create the Layout JSP with placeholders for header, footer, body and anything else you want by using Tiles insert tags. The insert tag is defined in struts-tiles.tld , the TLD file that is part of Struts distribution. The Layout JSP factors out most of the formatting markups . Typical things performed in a layout are:

Defining the outer structure of the page with html tables with defined widths.
Creating placeholders for pages relative to one another in the overall presentation scheme.

The first tag used in the listing above is getAsString . This tag retrieves the title as a string. The insert tags are used to insert different JSPs into the SiteLayout.jsp . For example the header of the page is inserted as: < tiles:insert attribute="header" / >. The layout we have used is simple. In reality however, nested tables with bells and whistles are used for professional looking pages. Although required, they result in indentation and hence error prone and visually displeasing. With the layout taking care of these two things, the individual pages don ‚ t have to deal it. That makes the design of included page simpler and cleaner.

Listing 7.2: SiteLayout.jsp ‚ The layout used by Tiles in the banking app

 <  %@ taglib uri="/WEB-INF/struts-tiles.tld" prefix="tiles" %  > <html:html locale="true"> <head>   <html:base/>   <title><tiles:getAsString name="title"/></title> </head> <body> <TABLE border="0" width="100%" cellspacing="5">   <tr><td><tiles:insert attribute="header"/></td></tr>   <tr><td><tiles:insert attribute="body"/></td></tr>   <tr><td><hr></td></tr>   <tr><td><tiles:insert attribute="footer"/></td></tr> </TABLE> </body> </html:html>

Step 2: Creating the XML Tile definition file

The SiteLayout.jsp created in the previous step uses the insert tag to insert the individual JSPs. The insert tags however do not specify the JSPs directly. They contain an attribute named attribute . The value of attribute is the reference to the actual JSP. The actual JSP name is specified in a XML based file called tiles definition. A sample definition is shown below.

 <definition name="/customer.page" path="/Sitelayout.jsp">   <put name="title" value="My Bank  Customer Form/>   <put name="header" value="/common/header.jsp" />   <put name="footer" value="/common/footer.jsp" />   <put name="body"   value="/CustomerDetail.jsp" /> </definition>

The Tiles definition shown above defines the JSPs that go into each of the insert tag placeholders in the SiteLayout.jsp for the Customer Details page and identify it them a unique name . Note that the name of each put in the definition is same as the value of attribute in the insert tag. Similarly a XML definition for the Success page is added as follows :

 <definition name="/success.page" path="/Sitelayout.jsp">   <  put name="title" value="MyBank  Success"/  >   <put name="header" value="/common/header.jsp" />   <put name="footer" value="/common/footer.jsp" />   <  put name="body"   value="/Success.jsp" /  > </definition>

Compare the above definition for the Customer Details Page definition shown earlier. You will see that only the title and body differ between the two. The header and footer remain the same. Tiles allows you to factor out these common elements in the definition and create a base definition. Individual definitions can then extend from the base definition, much like concrete classes extend from an abstract base class. Factoring out, the common elements of the two page definitions results in a base definition as:

 <definition name="base.definition" path="/Sitelayout.jsp">   <put name="title" value="MyBank/>   <put name="header" value="/common/header.jsp" />   <put name="footer" value="/common/footer.jsp" />   <put name="body"   value="" /> </definition>

The individual definitions are created by extending the above definition. Accordingly, the new definitions for Customer Detail and Success pages are as follows:

 <definition name="/customer.page" extends="base.definition">   <put name="title" value="MyBank  Customer Form/>   <put name="body"   value="/CustomerDetails.jsp" /> </definition> <definition name="/success.page" extends="base.definition">   <put name="title" value="MyBank  Success/>   <put name="body"   value="/Success.jsp" /> </definition>

Each of the definition extends from the base.definition and overrides the settings for title and body. They will however reuse the header and footer settings from the base.definition . Notice that we have left the body section blank in the base definition but provided a default title . Individual page definitions must provide the body JSP. If title is not provided, then the default title from the base definition is used.

The definitions thus created are stored in a file called tiles-defs.xml . Generally this file is placed under WEB-INF and is loaded at Struts startup. The file contains the definitions for each aggregate page (combination of several jsps) accessed by the user.

Step 3: Modifying the forwards in struts-config.xml

Suppose that you had the following action mapping in the struts-config.xml for the Customer form submission prior to using Tiles.

 <action   path="/submitCustomerForm"               type="mybank.app1.CustomerAction"               name="CustomerForm"               scope="request"               validate="true"               input="CustomerDetails.jsp">       <forward name="success"  path="Success.jsp"  />     </action>

The above action mapping uses the JSP name directly. With Tiles, you have to replace the JSP name with the tiles definition name. The resulting action mapping is shown below. The changes are highlighted in bold.

 <action   path="/submitCustomerForm"               type="mybank.app1.CustomerAction"               name="CustomerForm"               scope="request"               validate="true"  input="customer.page"  >       <  forward name="success"  path="success.page"  /  >     </action>

Step 4: Using TilesRequestProcessor

You have so far used org.apache.struts.action.RequestProcessor as the request processor with regular Struts pages. This request processor forwards to a specified JSP and commits the response stream. This does not work with Tiles as individual JSPs have to be included in the response stream even after the stream data is flushed and data is committed. Moreover, the regular Struts RequestProcessor can only interpret forwards pointing to direct physical resource such as a JSP name or another action mapping. It is unable to interpret ‚“ /customer.page ‚½ ‚ a Tiles definition. Hence Tiles provides a specialized request processor called TilesRequestProcessor to handle this scenario. For a given Struts module, only one request processor is used. A Tiles enabled module uses the TilesRequestProcessor , even if the module has regular Struts pages. Since TilesRequestProcessor extends from the regular Struts RequestProcessor , it inherits all its features and can handle regular Struts pages as well. TilesRequestProcessor is declared in the struts-config.xml as follows:

< controller processorClass=

 "org.apache.struts.tiles.TilesRequestProcessor"/>

The TilesRequestProcessor contains the logic to process includes and forwards. It checks if the specified URI is a Tiles definition name. If so, then the definition is retrieved and included. Otherwise the original URI is included or forwarded as usual.

Step 5: Configuring the TilesPlugIn

As you know, TilesRequestProcessor needs the XML Tiles definition at runtime to interpret Tiles specific forwards. This information created in Step 2 is stored in a file called tiles-defs.xml . Generally this file is placed under WEB-INF. At startup this file is loaded by using the Tiles PlugIn. The TilesPlugIn initializes Tiles specific configuration data. The plugin is added to the struts-config.xml as shown below.

 <plug-in className="org.apache.struts.tiles.TilesPlugin" >   <set-property property="definitions-config"                  value  ="/WEB-INF/tiles-defs.xml  " />   <set-property property="moduleAware" value="true"/> </plug-in>

The classname attribute refers to the plugin class that will be used. In this case org.apache.struts.tiles.TilesPlugin class is used.

Note ‚

CSS or Cascading Style Sheets is a way to add formatting rules and layout to existing HTML tags. CSS greatly simplifies changes to page appearance by only having to make edits to the stylesheets. Tiles, as we saw in the previous section deals with the organization of different parts of the JSP page as against enhancing the look and feel of individual components. CSS deals more with enhancing individual features of the components in each tile or area of the page. Tiles and CSS are complementary and can be used together to improve the look and feel of a JSP page.

In this section, you converted the Struts based Customer page and the subsequent page to use Tiles. The complete working application can be downloaded from the website (http://www.objectsource.com).

Rules of thumb

Although Tiles provides several ways to construct a page, some of them don ‚ t provide much advantage over the < jsp:include > approach at all. The approach we have illustrated above is usually the one used most. It is in this approach the real strength of Tiles get expressed .
Thanks to the multiple application module support in Struts 1.1, you don ‚ t have to Tiles enable your entire application and watch it collapse. Start by breaking the application into multiple modules. Test if the modules are working as expected. Also test inter-module navigation. Then Tiles-enable the modules one at a time. This provides you a rollback mechanism, if something goes wrong.
Never use the Tiles definition as the URL on the browser. This will not work. Struts can forward to a Tiles definition only when the control is within the TilesRequestProcessor , not when an external request arrives. If you want to display an aggregate Tiles page on clicking a link, define an action mapping for the URL (You can also use a global-forward instead). Then create an action mapping for a ForwardAction and set the parameter attribute to be the Tiles definition.

In the application shown earlier, JSPs were used as Tiles. You can also use action mappings as page names .

 <definition name="/customer.page" extends="base.definition">       <  put name="body"   value="/custdet.do" /  >    </definition>