February 28, 2021
Hot Topics:

Struts in Action: Developing Applications with Tiles

  • By Manning Publications Co.
  • Send Email »
  • More Articles »

11.5 Migrating an application to Tiles

At the beginning of this chapter we portrayed Tiles as a means of making your applications more consistent and easier to use. We also mentioned that consistency is a hallmark of good design. This is because consistency implies reuse. Reuse leads to applications that are hard to break and easy to maintain.

Often, you will have an existing application that you would like to adapt for Tiles. You may want it to improve the look so it is more consistent, or you may want to improve its functional design—or both. Improving the design of existing software is called refactoring [Fowler].

If you are familiar with conventional refactoring techniques, migrating an application to Tiles resembles the Extract Method. The tiles equate to methods that are called to render the page. When we are done, pages are reduced to a layout and a punch list of tiles to call. This works much like the central method in a class that just calls one member method after another.

Once we have extracted our tiles and reduced the page to a punch list, we can take the process a step further and replace the page with an XML element. Struts can use this element to render the tiles directly without bothering with a punch list page. But like all good refactorings, ours begins with the smallest step.

11.5.1 Setting up the Tiles framework

First, make an extra backup of everything, regardless of how many backups are made in the normal course. Migrating to Tiles can be tricky at first, and, realistically, you may need to make more than one pass before everything clicks into place. So be ready to roll back and try again. An extra backup on your desktop may be enough to lure you away from a three-hour debugging session spurred by some incidental typo.

Struts 1.0

If you haven't done so, the first step is to install the Tiles 1.0 package and load the Tiles servlet through your application's deployment descriptor. (See the package for details.) The 1.0 version of Artimus (see chapter 16) is based on Tiles and can be used for a working example. Then, test your application to be sure all is well by clicking through a few pages.

Also, be sure to set up a skeleton Tiles Definitions XML document so you can start filling it out as the refactoring proceeds.

Struts 1.1

Tiles is integrated with Struts 1.1. We cover the steps for enabling Tiles in Struts 1.1 in section 4.8 of this book.

11.5.2 Testing the default configuration

Set the debug and detail parameters in the deployment descriptor (web.xml) to level 2, and restart the application. Check the log entries carefully for any new error messages. Run any unit tests and click through the application to confirm that operation is still nominal.

11.5.3 Reviewing the pages

With Tiles up and running, the next thing is to take a good hard look at your pages and determine the overall layout types and the regions within each layout. It's also time to start thinking about a naming scheme. Each component will need its own identifier.

Identifying the layouts

When you look through an application, you will find varieties of menu or dialog pages—list pages, view pages, and edit pages—among others. Here the focus should not be on what the pages contain but how the parts of the page fit together. Does it have a header or a footer? Does it have a menu? Is the menu along the side or at the top? At this point, the relative position of elements like the navigation bar is more important than the actual links on the bar.

From this group, try to identify some common layouts. Again, the focus is on the visual layouts used throughout your application, not on the page content.

Identifying the tiles

Next take a closer look at each of the common layouts and identify the individual tiles. Determine how the parts of the page fit together. Then take a look at the page itself and identify the individual tiles. The presentation code for each tile will be saved as a separate file. We can use it in multiple layouts or edit it without touching the other tiles.

As mentioned, this process is similar to applying the Extract Method to a large Java class. One clue is to look for any existing comments in the presentation code, like <!-- menu starts here -- >. A block of markup prefaced with a comment is often a tile waiting to happen, like the block shown in listing 11.12.

Listing 11.12 A good candidate for a tile

<%-- messages --%><TR class="message"><TD colspan="3"><logic:messagesPresent>    <bean:message key="errors.header"/>    <html:messages id="error">      <LI><bean:write name="error"/></LI>    </html:messages>    <bean:message key="errors.footer"/></logic:messagesPresent></TD></TR>

Style changes in a page are also a good indicator of a potential tile. If the designer put in a style to set off a portion of the page, that portion of the page may make for a good tile.

The best candidate is a block of self-contained code with a single, coherent purpose—again, not unlike a Java method.

If the presentation code does not have comments like these, it can be helpful to add them to some representative pages before making a pass to extract the tiles. If a page segment looks like a tile, except that each page prints something different on the tile, don't despair. Tiles can also pass string constants to a tile so that the rest of the markup can be reused. For now, just put in a marker, like ${subtitle}, where the replacement string would go.

Naming the candidates

It can help to start working on a naming scheme early in the process. What we call a component can crystallize its purpose. We will need names for the individual regions, the general layouts, and each page in the system.

Table 11.3 shows the Tiles nomenclature for these entities: tile, layout, and definition.

Table 11.3 Tiles nomenclature
TileA reusable page fragment with HTML markup and JSP code.
LayoutA JSP that describes where to position the tiles on a page.
DefinitionA JavaBean that represents a particular page. The Definition combines a layout with a set of tiles and other runtime options to generate a distinct page. The Definition may be expressed as a JSP or contained in an XML configuration file.

The tiles are coherent fragments of text and markup that you will extract from your existing pages. Tiles can host static content or markup, or a mix of both. Most tiles represent navigational controls and other common assets and will be reused between pages. Common assets might include a table that positions a logo somewhere on a page or a set of buttons, like Save and Cancel, that are used on several forms. If a style is already associated with the asset, consider naming the tile after the style.

DEFINITION    Markup is the collection of commands placed in a file to provide formatting instructions rather than visible text or content. HTML uses a tag-based markup system.

Other tiles will contain content that is used on a single page. These tiles are often found at the center of the page surrounded by other tiles that provide the menu bars and other HTML chrome.

DEFINITION    The chrome is that part of the application window that lies outside a window's content area. Toolbars, menu bars, progress bars, and window title bars are all examples of elements that are typically part of the chrome. HTML chrome is created by markup and lies within the application window but serves the same purpose.

You can use the same conventions to name the tiles that you would use for any HTML or JSP. It can be useful to separate the shared tiles from those designed for a particular page. An easy way to do this is to open a tiles folder next to the folder you would usually use for your pages:

/pages  ./article/Form.jsp  ./channel/Channels.jsp/tiles  ./header.jsp  ./message.jsp

If a file resides in the tiles folder, it means that the file is meant to be used in more than one Definition. If a file resides in the pages folder, it means that the file contains unique content and is not expected to be shared.

The layouts are the containers for the tiles that describe where each component appears on the page. The layouts can be reused between Definitions. To keep everything together, you can create a layouts subdirectory beneath the tiles folder:

/tiles  ./header.jsp  ./message.jsp  ./layouts    ./Base.jsp    ./Remote.jsp

The Definitions are stored as elements in an XML document. Each Definition element needs its own name. In practice, the Definitions share namespace with the ActionForwards. The scheme should ensure that the ActionForward and Definition names do not collide. It can be helpful to group Definitions together in a directory/subdirectory type structure, so a name separator is also needed. One convention is to use a dot (.) for a separator in Definition names where many people might use a slash (/) in an ActionForward. To be sure there is no conflict with file system names, a leading dot can also be used where a leading slash would usually go:

<definition name=".account.logon"> . . . </definition>

Of course, any convention will do. You could use @ signs instead of dots, or preface each Definition with TILES: and then use slashes. Since these are logical references, any valid URI will do.

Once you have a general idea of what tiles, layouts, and Definitions you will need, and what you will call them, the next step is to extract the tiles and refactor a page.

Page 6 of 9

This article was originally published on April 17, 2003

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date