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-refname="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。