配置文件分解到逻辑分组之后,就会极大地降低应用程序的维护量。但是,还可以进一步采取几个方便的步骤,进一步降低配置的复杂性。首先,考虑典型的 web.xml 文件和这个文件中的大量标记库声明。作为示例,清单 7 显示了这份教程中使用的 Struts 银行示例的 web.xml 文件的最后一部分:
清单 7. web.xml 中的标记库声明
|
这里的问题不如查看成百上千行的 struts-config.xml 文件时那么明显,但是仍然是个问题。如果想使用其他标记库(例如 JSTL 标记库),问题就明显了,必须向 web.xml 文件添加另外一个或两个声明。这本身并不是一个立即可以发现的问题,直到您认识到 web.xml 会影响或破坏应用程序时才会发现。如果在这个文件中犯了小小的输入错误或者弄错了嵌套,那么整个应用程序可能会停止工作。它可能还意味着重启应用程序(进而意味着额外的测试,这会花时间,还有诸如此类的影响)。显然,这不是一个理想的配置情况。
那么考虑一个非常简单的解决方案:把标记库声明转移到 Java 服务器页面(JSP)中。例如,可以把清单 7 中的三个标记库声明转移到清单 8 所示的 JSP 中:
清单 8. JSP 文件中的标记库声明
|
现在,JSP 只需要添加一条 include
指令来包含这个 JSP 文件即可:
|
我通常把这个指令放在我的 JSP 的顶部。这样,从来不需要麻烦 web.xml 文件,应用程序不会因为添加一个标记库这么点儿小事就重启,我的应用程序也更加容易管理。我鼓励您也采取同样的转移,让自己少些麻烦。
|
这是另外一个 Struts 101 配置任务。在许多 Struts 书籍中都会找到它,包括 参考资料 中列出的 Struts Cookbook。同样,在许多书籍中都会有它,因为它是一个非常好的想法。
在 struts-config.xml 文件中已经看到过 message-resources
元素:
|
但是,不太有人知道:在 struts-config.xml 中这些元素可以放置不止一个。 例如,下面是非常合法的配置片断:
|
这里面的第一个元素(没有 key
属性)成为默认的资源集。所以所有的 JSP 和 servet 都可以通过 servlet 上下文访问这组资源。但是,通常是应用程序中的大块部分才需要资源。例如,前面的代码示例中包含的一组资源只针对应用程序的帮助部分(消息、图标、出错、字段标签等等),而且另一组资源特定于访客(没有登录的用户)。在核心应用程序、系统的帮助部分和访客屏幕之间,没有太多共享的信息。所以不必把所有这些资源混合到一个文件中,可以把它们分解到三个独立的文件中。
但是,比起使用三个(或多个)struts-config.xml 文件,这略有不同。在多个 stuts-config.xml 的情况下,多个文件实际上合并成一组配置数据。在多个资源束的情况下,多个文件没有 合并。相反,如果 JSP 页面想使用非默认的资源集,就必须指出要使用哪个资源(在这个示例中是 BankingMessageResources
包)。要做到这一点,需要使用 message
标记,它是 bean
标记库的一部分。
所以,假设:
- 把
bean
标记库与前缀bean
关联。 - 在
BankingHelpResources
包中有一个属性的键是help.label.seeAlso
。
要引用这个属性,应当在 JSP 中使用以下行:
|
额外的属性 bundle
允许指定要使用的非默认包,剩下的标记正常操作,就像访问默认包中的键一样。
您可能还注意到:即使有多个包,示例也只使用了一个特定于包的前缀:与帮助有关的资源在 BankingHelpResources
中,但是键仍然用 help
作为前缀,就像在 help.label.seeAlso
中那样。一开始这看起来可能是多余的,为什么在这个键只在特定于 help 的包中才可用的时候还用 help
做前缀呢?回答是:一切为了文档:
- 这样会让键的目的更加清晰:其他程序员就不必猜想这个键是做什么的(如果键只是
label.seeAlso
,可能就不那么清楚了)。 - 如果包的名称本身不太有说明性(可能有一些没有读过这份教程的初级程序员把它改成了
BankingExtraResources
),那么标签仍然可以帮助识别出键的目的。 - 如果想把资源从
BankingHelpResources
转移到另一个文件,那么键仍然会保留清晰性。
应当一直采用清楚的命名方式,不管您认为变量或键的上下文或使用方式让它们的目的有多么 清楚。