Recipe2.6.Using Multiple Resource Bundles

Recipe 2.6. Using Multiple Resource Bundles

Problem

You want to break apart your application resources properties file into multiple files for improved organization and easier maintenance, particularly in a team environment.

Solution

Create separate properties files and declare a message-resources element for each file in your struts-config.xml file:

<message-resources   parameter="com.oreilly.strutsckbk.MessageResources"/> <message-resources    parameter="com.oreilly.strutsckbk.LabelResources"   key="labels"> </message-resources> <message-resources    parameter="com.oreilly.strutsckbk.HeaderResources"   key="headers"> </message-resources>

Discussion

Struts uses a concept known as message resources to provide a mechanism for storing error messages, field labels, and other static text. With the default Struts implementation, you store the messages as name/value pairs in a .properties file. A message resources set is basically the same as a Java ResourceBundle.

You make your message resources properties file available to Struts using the message-resources element. The parameter attribute identifies the classpath-relative name of the properties file. You derive the value for this attribute by replacing the path separator in the file's path with a dot (".") and removing the .properties extension from the filename. For example, if the properties file was located in /WEB-INF/classes/com/oreilly/strutsckbk/MessageResources.properties, you would set up the message resources element as follows:

<message-resources   parameter="com.oreilly.strutsckbk.MessageResources"/>

On application startup, Struts creates a runtime representation of the message resources and stores it in the servlet context.

You are not limited to one set of message resources. However, unlike using multiple Struts configuration files, if you use multiple message resource files, they are not combined or merged. Instead, you define distinct sets of message resources. Each set is identified with a unique value specified using the key attribute. If this attribute isn't used, then that message resources set is created as the default set. Only one default set exists. Likewise, only one message resources set corresponds to each unique key within the same module. If you were to define multiple message resources bundles with the same key, the last one specified would be the one used.

The value of the key attribute serves as the name of the servlet context attribute under which the message resources bundle, created from the properties file, is stored. The key value is used in Struts tags, such as bean:message, to identify the message resources set, referred to as the bundle, from which to retrieve a property value. Here is how you would access a message from the labels message resources specified in the Solution:

<bean:message bundle="labels" key="label.url"/>

The value of the bundle attribute corresponds to the key attribute of the message-resources element in the struts-config.xml file. The bean:message tag has a key attribute that has a different meaning with of the message-resources element. It specifies the specify property to access from the message resources.

Unfortunately, this approach of using the same attribute for different purposes across XML elements and JSP tags is common in Struts. Make sure you keep the Struts taglib documentation (http://jakarta.apache.org/struts/userGuide/index.html) as well as the notes on configuring Struts (http://jakarta.apache.org/struts/userGuide/configuration.html#struts-config) bookmarked for handy reference to avoid confusion.

Struts doesn't care how you split your message resource property files. One approach is to split it by message type. For example, you could have separate message resource bundles for the following:

• Error messages

• Informational messages

• Field labels

• Table header cell text

While breaking up the message resources by these types is logical and reasonable, in a team environment it makes more sense to divide the resources by functional area. For example, consider a human resources application that has functional areas for payroll, benefits, and administration. You would create a message resources properties file for each of these areas. Each property file would have within it the error messages, field labels, and other message types specific to that area. If your development team has been divided around these business functional areas, breaking up configuration files in the same manner makes a lot of sense and reduces contention for these resources. The same approach can be used for splitting the Struts configuration file, as well.

If you are familiar with Struts modules, each of the functional areas mentioned above could be a good candidate for a Struts module. If you are using modules, the message resources you define in the struts-config file for a module only apply to that module. In fact, you can define message-resource elements in different modules that have the same key attribute. Recall from the discussion that Struts stores the MessageResources in the servlet context using the key value. More precisely, the actual value used is a concatenation of the module name, often referred to as the module prefix, with the message resources key attribute value.

See Also

Recipe 2.4 provides additional information on segregating application components. The Struts User Guide provides documentation on defining message resources that can be found at http://jakarta.apache.org/struts/userGuide/configuration.html#resources_config.

The JavaDoc API for the Struts MessageResources can be found at http://jakarta.apache.org/struts/api/org/apache/struts/util/MessageResources.html.

The Struts documentation on the bean:message tag can be found at http://jakarta.apache.org/struts/userGuide/struts-bean.html#message.