In this chapter you got an overview of Struts tags and more importantly learnt to customize these tags for your projects. In addition you
You will learn to use Tiles with Struts for web page design using Layouts
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
> approach. This approach is better than the previous one since it avoids repetition of common markup. The common markup
The team chose the second option at the time of development. However the new management directive is now
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 <
> for the common header and footer, but has the entire layout written in terms of html
. All JSPs in the application also might have the same layout
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
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
Comparing this approach with <
> will help you to understand the Tiles better. In the <
> 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