WebWork 学会配置action、result和interceptor

原文出处： http://www.blogjava.net/crespo9907/archive/2007/03/10/webworkinaction_note3.html，转载请保留。

      一、action  绝对的核心

      在实际应用中不出意外action总是一个扩展com.opensymphony.xwork.ActionSupport的Java类，或者说总是会继承ActionSupport（直接或间接）。我们在上篇笔记的HelloWorld程序中就可以知道WebWork的通过Servlet-Dispatcher（新版本已经更改为过滤器实现）接收道Http请求后分析特定的URL形式后调用action。如/hello.action样式的URL请求就调用了HelloWorld类的execute()方法。

      配置一个action需要的最少信息是action名和对应的action类。当它们添加到xwork.xml文件中时，就建立了一个action的映射。还是列出一个最简洁的例子：将action名login映射到Login类。
      

1 <! DOCTYPE xwork PUBLIC "-//OpenSymphony Group//XWork 1.1.1//EN"
2     "http://www.opensymphony.com/xwork/xwork-1.1.1.dtd" >
3
4 < xwork >
5        <!--  Configuration for the default package.  -->
6        < package  name ="default" >
7          < action  name ="login"  class ="com.wwinaction.webapp.actions.users.Login" />
8        </ package >
9 </ xwork >

      上面的代码中action标签是自封闭的，你肯定会想这有什么用啊？确实，除了象使用<ww:action/>标签这种极少数的情况下，没有result信息的action是没有什么实际作用的。幸运的是WebWork内置了几乎所有常用的result类型，当然你也可以建立自定义的result类型（在后面的笔记会详细介绍）。我们现在就来为上面的配置添加result吧，让它成为一个真正能在实际中使用的action。

 1 <! DOCTYPE xwork PUBLIC "-//OpenSymphony Group//XWork 1.1.1//EN"
 2     "http://www.opensymphony.com/xwork/xwork-1.1.1.dtd" >
 3
 4 < xwork >
 5        <!--  Include webwork defaults  -->
 6        < include  file ="webwork-default.xml" />
 7
 8        <!--  Configuration for the default package.  -->
 9        < package  name ="default"  extends ="webwork-default" >
10          < default-interceptor-ref  name ="defaultStack" />
11          < action  name ="login"  class ="com.wwinaction.webapp.actions.users.Login" >
12              < result  name ="input" > login.jsp </ result >
13              < result  name ="success" type="redirect" > /secure/dashboard.action </ result >
14          </ action >       
15         </ package >
16 </ xwork >

      比较上面两个例子有两个重要的变化：引入了webwork-default.xml以及加入了两个result节点。每个result都有一个名字、一个可选的类型和一个具体的值。当没有指定类型时就会使用package或者superpackage的默认result类型。在这种情况下就是webwork-default.xml文件中定义的dispatcher（分发器）。

      在上面的例子中，如果返回的result code是success那么用户就会被重定向到/secure/dashboard.action（这是另外一个action，现在暂时还没有定义，我们先不管它）。如果返回为input浏览器会在此显示login.jsp，并且用户刚才输入的信息还在，因为此时的类型为默认的分发器，action会把参数值继续传递给login.jsp。注意result映射可以是绝对路径也可以是相对路径。在讨论namespace概念的时候，这个会很重要。

      下面我们来讨论一下为action提供别名。在配置中每一个action节点就是一个action映射，但是也可以将多个名字映射到相同的action类。WebWork是一个实现了泛化command模式的框架。在默认情况下，WebWork调用action类的execute()方法。但是你也可以通过在action映射中增加一个可选的method属性，指定WebWork应该调用哪个方法。不过所指定的方法必须和execute()方法具有相同的“形状”，即没有输入参数，返回一个String类型的result code并且有选择的抛出异常。下面给出一个例子：

   

 1          < action  name ="users"  class ="com.wwinaction.webapp.actions.users.UserAction" >  
 2              < result  name ="success" > /WEB-INF/pages/userList.jsp </ result >  
 3          </ action >
 4         
 5          < action  name ="editUser"  class ="com.wwinaction.webapp.actions.users.UserAction"  method ="edit" >
 6              < result  name ="success" > /WEB-INF/pages/userForm.jsp </ result >
 7              < result  name ="input" > /WEB-INF/pages/userList.jsp </ result >
 8         </ action >
 9
10          < action  name ="editProfile"  class ="com.wwinaction.webapp.actions.users.UserAction"  method ="edit" >  
11              < result  name ="success" > /WEB-INF/pages/userForm.jsp </ result >
12              < result  name ="error" > /WEB-INF/pages/mainMenu.jsp </ result >
13          </ action >

      三个action均是关联到UserAction类，第一个执行默认的execute()方法，而后两个则执行edit()方法。（注：WebWork通过xwork.xml映射到方法有两种机制：通过查找与method属性值一致的方法；通过查找doMethod()形式的方法。这是为了兼容旧版本的一些做法，因为有些词是Java关键字不能作为方法名，如default。这个时候就把方法名写为doDefault，method值为default同样可以工作。不过上次看Struts的文档发现WebWork2迁移到Struts2后取消了这种机制，所以建议大家最好不要使用。）还有一个小技巧请大家注意：后两个action映射的方法都是一样，但是配置了两组不同的result，这也是action别名的好处之一。

      WebWork还有一种很方便的不需要配置的别名语法，支持形为name!method.action的映射。如上面的例子中，users!edit.action就会被映射到edit()方法中。在Struts2中可以通过设置打开或者关闭这种语法。

      附Struts2相关资源：
      WebWork2与Struts2的一些区别   http://struts.apache.org/2.x/docs/key-changes-from-webwork-2.html
      WebWork2如何迁移到Struts2   http://struts.apache.org/2.x/docs/webwork-2-migration-strategies.html

      我们还可以通过使用<param>标签来实现action的参数化，从而自定义action。举个例子就很好理解了：假如已经写好了一个处理Web Service请求的action，现在你可能需要将action的不同实例绑定到不同的URL，你也可能为每个action建立一个独立的timeout值。使用<param>标签你就可以使用同一个WebServiceAction类来实现你的想法。

 1 < action  name ="service1"  class ="com.example.WebServiceAction" >
 2    < result  name ="success" > /success.jsp </ result >
 3    < param  name ="url" > http://somesite.com/service.wsdl </ param >
 4    < param  name ="timeout" > 30 </ param >
 5 </ action >
 6
 7 < action  name ="service2"  class ="com.example.WebServiceAction" >
 8    < result  name ="success" > /success.jsp </ result >
 9    < param  name ="url" > http://somesite.com/service2.wsdl </ param >
10    < param  name ="timeout" > 60 </ param >
11 </ action >

 

 1 public   class  WebServiceAction  {
 2    private String url;
 3    private long timeout;
 4
 5    public void setUrl(String url) {
 6        this.url = url;
 7    }
 8
 9    public void setTimeout(long timeout) {
10        this.timeout = timeout;
11    }
12
13    public String execute() {
14        //执行相关操作
15    }
16}

      当action执行时，WebWork会自动根据action映射中指定的值调用相应的setter方法来设置这些参数值。当然这些都是借助与interceptor的魔力。眼尖的人可能发现了一个问题，那就是我们在<param>中配置的可以看作都是字符串，而这里的timeout为long类型，还能正常工作吗？回答是可以的，这借助了WebWork值得炫耀的自动类型转换功能，因为来自于外界的输入参数其实都是字符串形的，而在Java对象内部会有各种各样复杂程度不一的类型，它们之间的转换均交由WebWork的自动类型转换功能来处理，是多么的方便啊！这不也就是我们平时编程中最容易出错、最烦人和最耗时的工作吗？这么重要的功能我们当然会在后面专门的一篇中来讲述，在这里暂且按下不表。

      现在你至少应该知道action映射是如何配置了吧，下面我们就开始研究result映射和result类型吧。

      二、result  我们怎么显示呢？

      在WebWork应用程序中主要要配置两类与result相关的东西，一个是result类型，一个就是在上面的例子中反复出现的action的result。

      首先我们来看看如何配置result类型。其实在webwork-default.xml中就配置了很多默认的result类型，一般情况下这些就已经足够了，当然你也可以配置自己的result类型，和默认的配置方式是一致的。我们来看两个使用最多的result类型。

1 < result-types >
2      < result-type  name ="dispatcher"  class =""  default ="true" />
3      < result-type  name ="redirect"  class ="" />
4 </ result-types >

      result-types都是被包含在package中的，作为此package的类型设置，子package可以继承父package的result-types。因为这里关注的是如何配置result类型，所以class用...来代替。第一个result-typ比第二个多处了default="true"，这个表示此result类型被设置为默认的，当action中配置的result不指定type属性时就应用此默认result-types。

      讲一个关于result很重要的技巧，运用全局的result映射可以减少重复的配置。告诉你一个最简单的方法，你没必要在一开始就想办法应用此技巧，套用一个很流行的词汇这叫“过度设计”（当然很明显的例外），而是当你配置完action如果发现同一个package中多个action配置了同样的result时，你就可以应用这个技巧。下面我们来看个典型的例子。

1 < package  name ="default"  extends ="webwork-default" >
2      < global-results >
3          < result  name ="login" > /login!default.action </ result >
4          < result  name ="unauthorized" > /unauthorized.jsp </ result >
5      </ global-results >
6
7      <!--  other package declarations  -->
8 </ package >

      定义了login和unauthorized，一个对应登录页面而另一个对应没有管理员权限时用户被“丢去”的地方。显然这两种情况是常用的，定义为全局正好合适，省去了很多重复的配置，也显得更加清晰。

      在定义全局result的时候最好使用绝对路径，因为作为全局配置你现在并不能够确定它在什么context中被调用。所以使用绝对路径一劳永逸。

      三、interceptor   WW城中的大魔法师

      在决定性的攻城战中大魔法师可不是随意使用的，interceptor正是WebWork全面超越其他MVC框架的秘密武器！

      interceptor是在围绕action及result的执行过程中释放魔力的，然而在日常开发新的action的过程中，我们并不需要直接使用它们。典型的做法是创建一组或者一个堆栈的interceptor，并且在全局范围内将它们应用到action中。就像大魔法师的群疗术一样，一旦释放全屏补血。

      在实际开发过程中，一个package可能包含一组interceptor。用一个<interceptors>节点来包含若干个<interceptor>来实现。

1 < package  name ="default"  extends ="webwork-default" >
2      < interceptors >
3          < interceptor  name ="time"  class ="" />
4          < interceptor  name ="logger"  class ="" />
5      </ interceptors >
6
7      <!--  other code  -->
8 </ package >

      配置好interceptors后就可以应用到action中了。

 1 < package  name ="default"  extends ="webwork-default" >
 2      < interceptors >
 3          < interceptor  name ="time"  class ="" />
 4          < interceptor  name ="logger"  class ="" />
 5      </ interceptors >
 6
 7      < action  name ="login"  class ="" >
 8          < interceptor-ref  name ="timer" />
 9          < interceptor-ref  name ="logger" />
10          < result  name ="input" > login.jsp </ result >
11          < result  name ="success"  type ="redirect" > /secure/dashboard.action </ result >
12      </ action >
13 </ package >

      这个时候当login这个action被调用的时候timer和logger这两个interceptor也会相应的被调用来施放魔法。我们想象一下如果某个action需要配置一百个interceptor那我们岂不是要在action中写一百个interceptor这样的东西，如果你是一个正常的程序员你肯定会疯掉的。不过还好我们的大魔法师魔力无边，提供了interceptor-stack这样的一个东西来一系列的interceptor组合在一起形成一个stack，从而用stack来代替多个独立的interceptor，这个时候action就不需要做那么傻的事情了。

 1 < package  name ="default"  extends ="webwork-default" >
 2      < interceptors >
 3          < interceptor  name ="time"  class ="" />
 4          < interceptor  name ="logger"  class ="" />
 5      </ interceptors >
 6      < interceptor-stack  name ="myStack" >
 7          < interceptor-ref  name ="timer" />
 8          < interceptor-ref  name ="logger" />
 9      </ interceptor-stack >
10
11      < action  name ="login"  class ="" >
12          < interceptor-ref name ="myStack" />
13          < result  name ="input" > login.jsp </ result >
14          < result  name ="success"  type ="redirect" > /secure/dashboard.action </ result >
15      </ action >
16 </ package >

      可以看到action在引用一个独立的interceptor和包含多个interceptor的stack时都是使用interceptor-ref，并不会区别对待，这就使得一个interceptor stack又可以同时包含独立的interceptor和另外的interceptor stack。

      是不是非常的灵活，也节省大量的重复代码。WebWork尽量让代码量减少，不重复一句。这也是我们希望看到的，也是我们选择使用框架的原因。并不是有了框架就能够去除多变的需求，就能够编码如飞；框架仅仅是告诉我们什么不可以做，什么可以做，怎么样做最好。下面让我们继续减少重复配置和代码。

      前面的result应用全局的概念来减少配置的方法应该还记得吧，intercetpro同样也可以。（在coding的时候我们应该把多处的重复汇集到一起，从而减少重复；而在thinking的时候我们应该把一种思维和方法应用到多处去，从而提高质量）我们可以为每一个package建立一个默认的interceptor-ref。

 1 < package  name ="default"  extends ="webwork-default" >
 2      < interceptors >
 3          < interceptor  name ="time"  class ="" />
 4          < interceptor  name ="logger"  class ="" />
 5      </ interceptors >
 6      < interceptor-stack  name ="myStack" >
 7          < interceptor-ref  name ="timer" />
 8          < interceptor-ref  name ="logger" />
 9      </ interceptor-stack >
10
11      < default-interceptor-ref  name ="myStack" />
12
13      < action  name ="login"  class ="" >
14          < result  name ="input" > login.jsp </ result >
15          < result  name ="success"  type ="redirect" > /secure/dashboard.action </ result >
16      </ action >
17 </ package >

      这个时候package中的所有没有定义interceptor-ref的action都会应用此default-interceptor-ref指定的interceptor。并且一般情况下定义在同一包内的action都会应用相同的interceptor，所以这样可以节约很多配置和代码。不过 需要注意的是只有没有定义interceptor-ref的action才会应用这个默认配置，当为action指定了interceptor-ref时，此action只会应用这个interceptor-ref，而不是在default-interceptor-ref的基础上加上自己定义的interceptor。