WebWork In Action学习笔记(三) 学会配置action、result和interceptor

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

在上一篇笔记WebWork In Action学习笔记(二) WebWork方式的HelloWorld 中我们已经学会了如何构建一个简单的WebWork应用程序，除了创建几个简单的Java和Jsp程序外还配置了web.xml和xwork.xml。本篇我们就来继续讨论都是在xwork.xml中配置的action、result和interceptor三个极其重要的部分。正是它们实现了WebWork中优雅的MVC，result更是支持多种表现方式让开发Viewer变得更加容易，而interceptor则让WebWork变得异常强大并具有魔法。下面我们就开始吧！

一、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<!DOCTYPExworkPUBLIC"-//OpenSymphonyGroup//XWork1.1.1//EN"
2"http://www.opensymphony.com/xwork/xwork-1.1.1.dtd">
3
4<xwork>
5<!--Configurationforthedefaultpackage.-->
6<packagename="default">
7<actionname="login"class="com.wwinaction.webapp.actions.users.Login"/>
8</package>
9</xwork>

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

1<!DOCTYPExworkPUBLIC"-//OpenSymphonyGroup//XWork1.1.1//EN"
2"http://www.opensymphony.com/xwork/xwork-1.1.1.dtd">
3
4<xwork>
5<!--Includewebworkdefaults-->
6<includefile="webwork-default.xml"/>
7
8<!--Configurationforthedefaultpackage.-->
9<packagename="default"extends="webwork-default">
10<default-interceptor-refname="defaultStack"/>
11<actionname="login"class="com.wwinaction.webapp.actions.users.Login">
12<resultname="input">login.jsp</result>
13<resultname="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<actionname="users"class="com.wwinaction.webapp.actions.users.UserAction">
2<resultname="success">/WEB-INF/pages/userList.jsp</result>
3</action>
4
5<actionname="editUser"class="com.wwinaction.webapp.actions.users.UserAction"method="edit">
6<resultname="success">/WEB-INF/pages/userForm.jsp</result>
7<resultname="input">/WEB-INF/pages/userList.jsp</result>
8</action>
9
10<actionname="editProfile"class="com.wwinaction.webapp.actions.users.UserAction"method="edit">
11<resultname="success">/WEB-INF/pages/userForm.jsp</result>
12<resultname="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<actionname="service1"class="com.example.WebServiceAction">
2<resultname="success">/success.jsp</result>
3<paramname="url">http://somesite.com/service.wsdl</param>
4<paramname="timeout">30</param>
5</action>
6
7<actionname="service2"class="com.example.WebServiceAction">
8<resultname="success">/success.jsp</result>
9<paramname="url">http://somesite.com/service2.wsdl</param>
10<paramname="timeout">60</param>
11</action>

1publicclassWebServiceAction{
2privateStringurl;
3privatelongtimeout;
4
5publicvoidsetUrl(Stringurl){
6this.url=url;
7}
8
9publicvoidsetTimeout(longtimeout){
10this.timeout=timeout;
11}
12
13publicStringexecute(){
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-typename="dispatcher"class=""default="true"/>
3<result-typename="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<packagename="default"extends="webwork-default">
2<global-results>
3<resultname="login">/login!default.action</result>
4<resultname="unauthorized">/unauthorized.jsp</result>
5</global-results>
6
7<!--otherpackagedeclarations-->
8</package>

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

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

三、interceptor WW城中的大魔法师

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

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

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

1<packagename="default"extends="webwork-default">
2<interceptors>
3<interceptorname="time"class=""/>
4<interceptorname="logger"class=""/>
5</interceptors>
6
7<!--othercode-->
8</package>

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

1<packagename="default"extends="webwork-default">
2<interceptors>
3<interceptorname="time"class=""/>
4<interceptorname="logger"class=""/>
5</interceptors>
6
7<actionname="login"class="">
8<interceptor-refname="timer"/>
9<interceptor-refname="logger"/>
10<resultname="input">login.jsp</result>
11<resultname="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<packagename="default"extends="webwork-default">
2<interceptors>
3<interceptorname="time"class=""/>
4<interceptorname="logger"class=""/>
5</interceptors>
6<interceptor-stackname="myStack">
7<interceptor-refname="timer"/>
8<interceptor-refname="logger"/>
9</interceptor-stack>
10
11<actionname="login"class="">
12<interceptor-ref name="myStack"/>
13<resultname="input">login.jsp</result>
14<resultname="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<packagename="default"extends="webwork-default">
2<interceptors>
3<interceptorname="time"class=""/>
4<interceptorname="logger"class=""/>
5</interceptors>
6<interceptor-stackname="myStack">
7<interceptor-refname="timer"/>
8<interceptor-refname="logger"/>
9<span style

分享到：

SSI使用详解 | JBoss在开发模式下部署自己指定路径项目（ ...

• 2009-03-27 11:29
• 浏览 934
• 评论(0)
• 查看更多