关注WebWork（五） —— 配置之美

        看到这样的题目，看到“配置”这个key word，你的脑海中是不是会呈现出一堆堆的XML、properties文件呢？是的，我说的配置，就是各位平常在做项目的时候经常碰到的配置文件。在一个项目中，配置文件是很重要的，不管它是简短的还是冗长的。配置文件指出了一个系统中可变化、可设定的部分，也就是说一个系统将其中一部分信息独立出来，将设定这些信息的权利交给了用户，这样用户就可以根据自己的需要来进行设定，从而增强了系统的灵活性及适应性。
        虽然配置文件很重要，但是它通常都给人以冗长而繁琐的感觉。哪怕现在绝大多数的配置文件都是XML，哪怕XML本身也是自描述的，配置文件都很难给人以一种美感，它在大部分情况下实在是太冗长了。在我现在所做的一个使用Portal的项目中，配置文件portlet.xml的行数就高达六千行以上，web.xml也有近三千行！这样的配置文件除了给机器看之外，没有人愿意去看它了。难道配置文件由始至终都是那样丑陋吗？在接触WebWork之前，我确实就是这样认为的，但是当WebWork的配置文件呈现在眼前的时候，我的偏见彻底被颠覆了，我发现配置文件原来也可以那样的美。不信？让我们看看去！
        与WebWork相关的配置文件有三个：通用的web.xml、xwork.xml和webwork.properties。web.xml中的配置跟其他的框架一样，保持着简练的风格。如果你不打算使用WebWork的标签库，就只需要在web.xml中定义好作为Request Dispatcher的Servlet即可：

<web-app>
<servlet>
    <servlet-name>webwork</servlet-name>
    <servlet-class>com.opensymphony.webwork.dispatcher.ServletDispatcher</servlet-class>
</servlet>
<servlet-mapping>
    <servlet-name>webwork</servlet-name>
    <url-pattern>*.action</url-pattern>
</servlet-mapping>
</web-app>

        而webwork.properties中则是定义了很多与Web Application相关的属性，便于你进行配置。在应用程序中你可以直接通过Configuration类的getString方法访问到文件中定义的属性值，非常方便。同时，这些属性涵盖的面很广，除了常见的locale、encoding等，还有以下几个特别的属性：
        webwork.custom.properties：用于指定外部的properties配置文件。应用程序可以通过Configuration类的getString方法很容易地访问到外部配置文件中的属性值，这跟访问webwork.properties文件中属性值的方式是完全一致的。webwork.custom.properties属性是相当有用的，当你需要增加一些应用程序所特有的属性值时，你可以把这些属性值定义在一个或者几个properties文件中，还可以将这些properties文件存放到相应的module里面，这样就会使得你的应用程序结构更加清晰，更易于管理。以下是一个简单的例子。譬如应用程序有两个module：一个是Investment(代码存放在com.fantasysoft.investment中)，另一个是Banking(代码存放在com.fantasysoft.banking中)。我们为这两个module创建相应的properties文件：investment.properties和banking.properties，而这两个配置文件可以分别存在各自的package中。最后我们只要将webwork.custom.properties的值作如下设定，就可以访问这两个.properties了：

webwork.custom.properties = com/fantasysoft/banking/banking, com/fantasysoft/investment/investment

        
        webwork.action.extension：用于改变action对应的扩展名。在默认的情况下，action对应的扩展名是action，但是你也可以改为你喜欢的名字，譬如do。如果你改变了这个值之后，别忘了更新web.xml中servlet-mapping的设置哦；
        webwork.tag.altSyntax：用于设置使用哪一种JSP Syntax，可选值为true或者false。详情请参见我之前的Post——关注WebWork（三）； 
        webwork.configuration.xml.reload：用于设置是否支持配置文件在运行期的重新装载，可选值也是true或者false，默认值为false。一旦将这个属性设为true，在你修改了任何配置文件之后，WebWork都会自动装载最新的内容，这免去了重新启动项目或者服务器的繁琐过程，大大提高了开发效率。

        webwork.properties就讲到这里，接下来轮到三个配置文件中的最重量级成员——xwork.xml出场了。xwork.xml可以说是WebWork配置文件的核心部分，因为action、result以及interceptor都是在这里定义的。这样乍一听，你或许会觉得一个大型项目中的xwork.xml一定会很庞大。嗨，你可别忘了这篇Post的标题是配置之美噢，冗长又何来美呢？
        xwork.xml的最大特点是：它很灵活，一切都从如何减少配置的重复性去考虑；它具有很多面向对象的概念，譬如继承、组合、namespace和package等等。一个简单而实用的xwork.xml是这样的：

<xwork>
<include name="webwork-default.xml"/>
<package name="default" extends="webwork-default">
<default-interceptor-ref name="defaultStack"/>
<action name="login" class="com.fantasysoft.Login">
<result name="input">login.jsp</result>
<result name="success" type="redirect">loginSuccess.jsp</result>
</action>
</package>
</xwork>

这里包含了几个知识点：
        1、action的定义：这一点很简单，只需要提供action的名字和对应的Java类即可；
        2、result的定义：result的定义也很简单，提供result的名字、result的值(也就是login.jsp和loginSuccess.jsp)和result的type(redirect)即可。对于第一个名为input的result，虽然没有没有定义type，但是使用了默认的type：dispatcher。至于这个默认的type存在哪里呢？在以下的内容将会详细介绍；
        3、interceptor的引用：XML中的<default-interceptor-ref name="defaultStack"/>就是对interceptor或者是interceptor栈的引用。从tag的命名default-interceptor-ref可以知道这个interceptor(interceptor栈)是默认的设置，也就是所有的action在没有定义自己特有的interceptor引用的时候，都会使用这个默认的interceptor引用；
        4、include标签的使用：通过include标签可以xwork.xml包含另外的XML文件，当然被包含的XML也必须符合同样的DTD。这个特性是相当有用的，因为一个大型的应用程序需要划分为众多小型模块进行开发，而每个小模块又可以拥有自己的xwork.xml文件，模块之间互不影响。到了将这些小模块合并的时候，只需要将这些小模块各自的xwork.xml文件改名并且通过include标签包含到全局的xwork.xml即可，从而简化了应用程序的打包发布过程。
        5、package的使用：所有的关于action、result、interceptor等等的设置都是囊括在package之下的，一个合法的xwork.xml必须指明使用的package。对于package的概念，关键是extends的使用。通过extends声明就可以引入被扩展的package所定义的设置，这跟OO中的继承是相当类似的。当一个配置在当前的package找不到的时候，就会到父package中查找，如果还是找不到，就将一直追溯到package继承体系的根节点了。上面的第二点所说的默认result type就是在webwork-default这个package中被定义的。对于package还有一个重要的知识点需要记住：package名字在整个应用程序中不能被重复定义，必须是唯一的。
        一个简单的xwork.xml里面确实暗藏乾坤啊，而这里也只是讲述了部分内容。但是从这些简单的内容，你应该可以感觉到WebWork设计者的一番良苦用心：竭力减少冗余，促进模块化。而事实上，他们确实做到了，因为呈现在我们面前的配置文件简单明了而且脉络清晰。