struts 分写成多个配置文件

摆脱标记库声明

配置文件分解到逻辑分组之后，就会极大地降低应用程序的维护量。但是，还可以进一步采取几个方便的步骤，进一步降低配置的复杂性。首先，考虑典型的 web.xml 文件和这个文件中的大量标记库声明。作为示例，清单 7 显示了这份教程中使用的 Struts 银行示例的 web.xml 文件的最后一部分：

清单 7. web.xml 中的标记库声明

  <taglib>    <taglib-uri>/WEB-INF/struts-html.tld</taglib-uri>    <taglib-location>/WEB-INF/struts-html.tld</taglib-location>  </taglib>  <taglib>    <taglib-uri>/WEB-INF/struts-bean.tld</taglib-uri>    <taglib-location>/WEB-INF/struts-bean.tld</taglib-location>  </taglib>  <taglib>    <taglib-uri>/WEB-INF/struts-logic.tld</taglib-uri>    <taglib-location>/WEB-INF/struts-logic.tld</taglib-location>  </taglib>

这里的问题不如查看成百上千行的 struts-config.xml 文件时那么明显，但是仍然是个问题。如果想使用其他标记库（例如 JSTL 标记库），问题就明显了，必须向 web.xml 文件添加另外一个或两个声明。这本身并不是一个立即可以发现的问题，直到您认识到 web.xml 会影响或破坏应用程序时才会发现。如果在这个文件中犯了小小的输入错误或者弄错了嵌套，那么整个应用程序可能会停止工作。它可能还意味着重启应用程序（进而意味着额外的测试，这会花时间，还有诸如此类的影响）。显然，这不是一个理想的配置情况。

那么考虑一个非常简单的解决方案：把标记库声明转移到 Java 服务器页面（JSP）中。例如，可以把清单 7 中的三个标记库声明转移到清单 8 所示的 JSP 中：

清单 8. JSP 文件中的标记库声明

<%@ page contentType="text/html;charset=UTF-8" language="java" %><%@ taglib uri="http://jakarta.apache.org/struts/tags-html"    prefix="html" %><%@ taglib uri="http://jakarta.apache.org/struts/tags-bean"    prefix="bean" %><%@ taglib uri="http://jakarta.apache.org/struts/tags-logic"    prefix="logic" %>

现在，JSP 只需要添加一条 include 指令来包含这个 JSP 文件即可：

<!-- Include the standard tag library JSP --><%@ include file="/config/taglibs.jsp" %>

我通常把这个指令放在我的 JSP 的顶部。这样，从来不需要麻烦 web.xml 文件，应用程序不会因为添加一个标记库这么点儿小事就重启，我的应用程序也更加容易管理。我鼓励您也采取同样的转移，让自己少些麻烦。

使用多个消息资源束

这是另外一个 Struts 101 配置任务。在许多 Struts 书籍中都会找到它，包括 参考资料 中列出的 Struts Cookbook。同样，在许多书籍中都会有它，因为它是一个非常好的想法。

在 struts-config.xml 文件中已经看到过 message-resources 元素：

<message-resources parameter="BankingMessageResources" null="false"/>

但是，不太有人知道：在 struts-config.xml 中这些元素可以放置不止一个。 例如，下面是非常合法的配置片断：

<message-resources parameter="BankingMessageResources" null="false"/><message-resources parameter="BankingHelpResources" key="help"/><message-resources parameter="BankingGuestUserResources" key="guest"/>

这里面的第一个元素（没有 key 属性）成为默认的资源集。所以所有的 JSP 和 servet 都可以通过 servlet 上下文访问这组资源。但是，通常是应用程序中的大块部分才需要资源。例如，前面的代码示例中包含的一组资源只针对应用程序的帮助部分（消息、图标、出错、字段标签等等），而且另一组资源特定于访客（没有登录的用户）。在核心应用程序、系统的帮助部分和访客屏幕之间，没有太多共享的信息。所以不必把所有这些资源混合到一个文件中，可以把它们分解到三个独立的文件中。

但是，比起使用三个（或多个）struts-config.xml 文件，这略有不同。在多个 stuts-config.xml 的情况下，多个文件实际上合并成一组配置数据。在多个资源束的情况下，多个文件没有 合并。相反，如果 JSP 页面想使用非默认的资源集，就必须指出要使用哪个资源（在这个示例中是 BankingMessageResources 包）。要做到这一点，需要使用 message 标记，它是 bean 标记库的一部分。

所以，假设：

• 把 bean 标记库与前缀 bean 关联。
• 在 BankingHelpResources 包中有一个属性的键是 help.label.seeAlso。

要引用这个属性，应当在 JSP 中使用以下行：

<bean:message bundle="help" key="help.label.seeAlso" />

额外的属性 bundle 允许指定要使用的非默认包，剩下的标记正常操作，就像访问默认包中的键一样。

您可能还注意到：即使有多个包，示例也只使用了一个特定于包的前缀：与帮助有关的资源在 BankingHelpResources 中，但是键仍然用 help 作为前缀，就像在 help.label.seeAlso 中那样。一开始这看起来可能是多余的，为什么在这个键只在特定于 help 的包中才可用的时候还用 help 做前缀呢？回答是：一切为了文档：

• 这样会让键的目的更加清晰：其他程序员就不必猜想这个键是做什么的（如果键只是 label.seeAlso，可能就不那么清楚了）。
• 如果包的名称本身不太有说明性（可能有一些没有读过这份教程的初级程序员把它改成了 BankingExtraResources），那么标签仍然可以帮助识别出键的目的。
• 如果想把资源从 BankingHelpResources 转移到另一个文件，那么键仍然会保留清晰性。

应当一直采用清楚的命名方式，不管您认为变量或键的上下文或使用方式让它们的目的有多么 清楚。