A look at the Composite design pattern

Treat primitive and composite objects the same way

1 2 3 Page 3
Page 3 of 3

The URL for each href attribute is the same: flags.do. Two request parameters are tacked onto that URL: one for the locale corresponding to the flag and another that represents the current JSP's path. You obtain the latter request parameter by invoking the Http.ServletRequest.getServletPath() method.

In the application's deployment descriptor, I mapped all URLs ending in .do to the Struts action servlet, like this:

Example H2. WEB-INF/web.xml (Excerpt)

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
  PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"
     <!-- Action Servlet Configuration -->
     <!-- Action Servlet Mapping -->

Note: See my "Take Command of Your Software" (JavaWorld, June 2002) article for more information about Struts and the Struts action servlet.

Next, I mapped the path /flags to the Struts action actions.FlagAction in the Struts configuration file, listed in Example H3:

Example H3. WEB-INF/struts-config.xml

<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE struts-config PUBLIC
  "-//Apache Software Foundation//DTD Struts Configuration 1.1//EN"
      <action path='/flags' type='actions.FlagAction'/>
   <plug-in className="org.apache.struts.tiles.TilesPlugin" >
        <set-property property="definitions-config" 
                       value="/WEB-INF/tiles-defs.xml" />
        <set-property property="definitions-debug" value="2" />
        <set-property property="definitions-parser-details" 
                       value="2" />
        <set-property property="definitions-parser-validate" 
                       value="true" />

Because of that mapping, the URL flags.do causes the Struts action servlet to invoke the actions.FlagAction.execute() method; therefore, clicking on a flag will invoke the actions.FlagAction.execute() method. Example H4 lists the actions.FlagAction class:

Example H4. WEB-INF/classes/actions/FlagAction.java

package actions;
import javax.servlet.ServletContext;
import javax.servlet.http.*;
import org.apache.struts.action.*;
import javax.servlet.jsp.jstl.core.Config;
public class FlagAction extends Action {
   public ActionForward execute(ActionMapping mapping, 
                                ActionForm form,
                                HttpServletRequest request, 
                                HttpServletResponse response)
                         throws java.io.IOException, javax.servlet.ServletException {
      String locale = request.getParameter("locale");
                 Config.FMT_LOCALE, locale);
      return new ActionForward(request.getParameter("fwdPage"));

The actions.FlagAction.execute() method obtains a reference to the locale request parameter and passes that value to the JSTL Config class's set() method. That method stores the string representing the locale in the FMT_LOCALE configuration setting, which JSTL uses to localize text and format numbers, currencies, percents, and dates.

Now that I've specified a locale for JSTL internationalization actions, I next specify a resource bundle in the application's deployment descriptor, an excerpt of which is listed in Example H5:

Example H5. WEB-INF/web.xml (Excerpt)

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
  PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"
     <!-- Define the basename for a resource bundle for I18N -->

The resource bundle basename resources is specified for the javax.servlet.jsp.jstl.fmt.localizationContext context-initialization parameter. That means JSTL will search for a file named resources_en.properties when the locale is set to British English (en-GB) and resources_zh.properties when the locale is set to Chinese (zh-ZH).

Now that I've specified a resource bundle and a locale for the JSTL internationalization actions, I next modify the JSP files to use those actions, as Examples H6-H9 demonstrate:

Example H6. sidebar-links.jsp

<%@ page contentType='text/html; charset=UTF-8' %>
<%@ taglib uri='http://java.sun.com/jstl/fmt' prefix='fmt' %>
<font size='5'><fmt:message key='sidebar.heading'/></font><p>
<a href='index.jsp'><fmt:message key='sidebar.link.1.name'/></a><br>
<a href='products.jsp'><fmt:message key='sidebar.link.2.name'/></a><br>
<a href='downloads.jsp'><fmt:message key='sidebar.link.3.name'/></a><br>
<a href='sales.jsp'><fmt:message key='sidebar.link.4.name'/></a><br>
<a href='contact.jsp'><fmt:message key='sidebar.link.5.name'/></a><br>

Example H7. header.jsp

<%@ page contentType='text/html; charset=UTF-8' %>
<%@ taglib uri='http://java.sun.com/jstl/fmt' prefix='fmt' %>
<font size='6'><fmt:message key='header.heading'/></font>

Example H8. content.jsp

<%@ page contentType='text/html; charset=UTF-8' %>
<%@ taglib uri='http://java.sun.com/jstl/fmt' prefix='fmt' %>
<font size='4'><fmt:message key='content.heading'/></font>

Example H9. footer.jsp

<%@ page contentType='text/html; charset=UTF-8' %>
<%@ taglib uri='http://java.sun.com/jstl/fmt' prefix='fmt' %>
<fmt:message key='footer.message'/>

Examples H6-H9's JSPs use the JSTL <fmt:message> action to extract Unicode strings from the resource bundle specified in the deployment descriptor. Examples H10 and H11 list the resource bundles for English and Chinese, respectively:

Example H10. WEB-INF/classes/resources_en.properties

header.heading=Welcome to Sabreware, Inc.
content.heading=Page-specific content goes here
footer.message=Thanks for stopping by!
sidebar.link.5.name=Contact Us

Example H11. WEB-INF/classes/resources_zh.properties

header.heading=\u5bc6\u7801\u63d0\u793a\u95ee\u9898 Sabreware, Inc.


In an email to me, Joseph Friedman wrote:

In "Decorate Your Java Code" (JavaWorld, December 2001), you write:

"The enclosing object—known as a decorator—conforms to the interface of the object it encloses, allowing the decorator to be used as though it were an instance of the object it encloses."

However, the code example decorates the FileReader with a LineNumberReader and calls readLine(), which is not in the FileReader interface; thus you are not using the LineNumberReader transparently.

Both FileReader and LineNumberReader conform to the interface defined by the Reader class, which they both extend. The idea is that you can pass the decorator to any method that expects a reference to a Reader. Those methods remain blissfully ignorant of that decorator's special capabilities—in this case, the ability to read files and produce line numbers. However, if you know about those special capabilities, you can take advantage of them.

The fact that the decorator possesses (one or more) methods that the decorated object lacks does not in any way violate the Decorator pattern's intent; in fact, that's the central feature of that pattern: to add functionality at runtime to an object by decorating objects recursively.

If you look at Design Patterns page 173, you will see this:

Decorator subclasses are free to add operations for specific functionality. For example, ScrollDecorator's ScrollTo operation lets other objects scroll the interface *if* they know there happens to be a ScrollDecorator object in the interface.
David Geary is the author of Core JSTL Mastering the JSP Standard Tag Library, which will be published this fall by Prentice-Hall and Sun Microsystems Press; Advanced JavaServer Pages (Prentice Hall, 2001; ISBN: 0130307041); and the Graphic Java series (Sun Microsystems Press). David has been developing object-oriented software with numerous object-oriented languages for 18 years. Since the GOF Design Patterns book was published in 1994, David has been an active proponent of design patterns, and has used and implemented design patterns in Smalltalk, C++, and Java. In 1997, David began working full-time as an author and occasional speaker and consultant. David is a member of the expert groups defining the JSP standard custom tag library and JavaServer Faces, and is a contributor to the Apache Struts JSP framework.

Learn more about this topic

1 2 3 Page 3
Page 3 of 3