Struts in Action: Developing Applications with Tiles
This is Chapter 11: Developing Applications with Tiles from the book Struts in Action (ISBN:1-93011-050-2), written by Ted N. Husted, Cedric Dumoulin, George Franciscus, and David Winterfeldt, published by Manning Publications Co..
© Copyright Manning Publications Co. All rights reserved.
Developing Applications with Tiles
Co-authored by Cedric Dumoulin and Ted Husted
This chapter covers
- Designing applications with dynamic includes
- Using the Struts and Tiles frameworks together
- Understanding Tiles Definitions and attributes
- Migrating applications to Tiles
A foolish consistency is the hobgoblin of little minds, adored by littlestatesmen and philosophers and divines.
Ralph Waldo Emerson
11.1 Leveraging layouts
Usability is a prime concern in the design of today's applications—and consistency is a prime ingredient of usability. Users want to stay focused on the task at hand and are easily annoyed by any small inconsistency in an application's interface or screen layout.
Consistency is no small challenge for a dynamic web application; it is commonplace for each page to be coded by hand. Layout tools for static pages are available to most designers today, but few of these are available to applications based on JavaServer Pages.
Worse, the look and feel of an application is usually the last detail to be finalized, and then it will often change between versions—or even arbitrarily as part of a greater website "relaunch." This can create a nightmarish round of last-minute coding and testing—even if only to alter the background color or add a new link to the menu bar.
Of course, consistency is more than a hobgoblin; it's a hallmark of good design. Like any other component, web pages contain many common elements, headers, footers, menus, and so forth. Often, these are cut-and-pasted from one page to the next. But like any component, bugs are found and features are enhanced, leading to another round of cut-and-paste "reuse."
In a web application, page markup is a programming component like any other and should be held to the same standard of reuse.
11.1.1 Layering with dynamic templates
In the first part of this book, we stressed the importance of layering an application to isolate the effects of change. By compartmentalizing an application, we can change one piece without disrupting the other pieces. The same concept can be applied within the presentation layer to separate the look and feel from the actual content.
One approach to separating layout from content is the use of dynamic JSP includes. The JSP specification provides for both static and dynamic includes. The standard JSP action for a dynamic include is <jsp:include>.
We make use of dynamic includes by breaking the server page into several fragments, each with its own job to do. A background template can set the default format and layout, and page fragments can be included at runtime to provide the content. A dynamic include folds the output of the included page into the original page. It acts like a switch that moves processing over to a page fragment and then back to the caller. As shown in figure 11.1, the included template is processed normally, just as if it had been called on its own.
Figure 11.1 The effect of the <jsp:include> action on the processing of a request
The Tiles framework, which we explore in this chapter, uses a more advanced form of the JSP include action. In a Tiles application, the background, or layout, template usually defines the position of a header, menu body, content, and footer. Other pages are then included to fill each of these positions. If the header changes, then only that template file need be changed. The change is automatically reflected in all pages that include that template. The effects of changes are minimized’and the hobgoblins appeased.
Standard HTML components, like Cascading Style Sheets (CSSs), also work well with dynamic templates. A style sheet can help keep the templates internally consistent and further minimizes the effects of change.
11.1.2 Template consequences
Every technology comes bundled with compromises. Here are some consequences—pro, con, and mixed—that come with using dynamic templates in your application:
- The JSP include technology is well established and reliable, and tends to scale well in larger applications. The underlying technology for including dynamic templates is part of the core Java Servlet API.
- Most containers are optimized for JSPs and standard features like servlet include.
- The included pages typically output HTML fragments and are not synoptically complete. This can prevent you from maintaining templates with standard HTML editors, which expect markup to be part of a complete, stand-alone page.
- Most sites recompile JSP pages when the source changes. Templates create more pages to be monitored for such changes.
- Templates actually reuse code that would otherwise be duplicated from page to page. This can result in a significantly smaller footprint and conserve server resources.
11.1.3 Using templates
We take a close look at using dynamic templates in this chapter, especially as the Tiles framework implements them. Tiles is a mature product and integrates well with the Struts framework. Tiles templates can even be deployed from a Struts ActionForward, eliminating a good many "red tape" files other template systems require.Struts and Tiles are a powerful combination. Using dynamic templates to generate presentation pages jibes well with the other programming practices involved in writing a web application. In this chapter, we show how to best combine Tiles with Struts and other assets, like CSS. After introducing Tiles, we provide a refactoring guide to help you migrate an existing product to Tiles.
If you find that Tiles is a good match for your application, be sure to study the example application in chapter 15. See table 11.1 for a glossary of some of the special terms we use in this chapter.
|Table 11.1 A glossary of dynamic template terms|
|Dynamic element||A portion of a JSP that is recognized by the JSP translator, including an action, directive, expression, JSP tag, or scriptlet.|
|Template data||A portion of a JSP that is not recognized by the JSP translator and is passed to the response verbatim. Usually markup and visible text.|
|Template page||A JSP that includes, or is included by, another page.|
|Template file||A static file or JSP that is included by a template page.|
|Tile||A synonym for template page.|
|Layout||A description of where template files, or tiles, should be positioned on a page.|
|Tiles||A framework that makes templates and layouts easier and more powerful.|
|Definition||A Tiles feature that allows a layout to be specified as a template page or as a JavaBean. Definitions can also be described by an XML document.|
11.1.4 Combining templates, Tiles, and Struts
When HTML tables were first invented, page designers immediately adopted them as a layout mechanism. A borderless table can be used to contain other tables and content and create layouts that were otherwise impossible.
The same idea is often used with dynamic templates. As shown in figure 11.2, a master template is used to provide the layout for the page and position the elements; page fragments are then included to fill in the elements. The page fragments can be included in any type of layout: those that use borderless tables, those that use <div> tags, and even very simple layouts that just stack one component over the other.
Figure 11.2 A master template provides the layout for a page.
Tiles is a framework that makes using template layouts much easier through use of a simple but effective tag library. It can be used as a drop-in replacement for the Template taglib distributed with Struts 1.0 but provides more functionality. The Tiles package can be used with any JSP application.
|1.0 vs 1.1||Tiles is bundled with Struts 1.1. Configuring Tiles for Struts 1.1 is covered in chapter 4. Tiles is also available for Struts 1.0. See the Extensions category on the Struts Resources page for details [ASF, Struts].|
Most often, a JSP template system will use one template for the layout and another for the fill-in components. Tiles calls these layout files Definitions. Most template systems require that an extra file be used just to specify the layout. To avoid this overhead, Tiles allows the layout Definitions to be stored as a JavaBean. What's more, there is an extension to Struts that allows Definitions to be the target of an ActionForward. This is an exciting feature, which we discuss in section 11.3.3. In section 11.5, we return to Definitions again when we walk through refactoring an existing product into a Tiles-based application using Definitions and Struts.
But, for now, let's start at the beginning and create a new layout from scratch.