随笔档案

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


      比较上面两个例子有两个重要的变化：引入了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并且有选择的抛出异常。下面给出一个例子：

   
      三个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类来实现你的想法。



      当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类型。


      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时，你就可以应用这个技巧。下面我们来看个典型的例子。


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

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

      三、interceptor   WW城中的大魔法师

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

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

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


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


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


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

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

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


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

      在后面的笔记中我们还会分别详细的介绍这三个WebWork中最重要的组成部分，本来打算把webwork.properties的相关配置记一下，好像也没这个必要，再写也就是把官方文档的内容贴在这里，还是有问题就去看官方的文档好。框架学习要养成多看文档和API的好习惯，在一定的时候研读源代码也会对编程水平有非常大的提高而不仅仅在于使用这个框架了。

      《WebWork in Action》这本书已经看完很久了，因为种种的原因笔记现在才补上。但在补写笔记的时候发现了好多书中之前没有注意到关键内容和对以前内容的一个重新理解和衍生。我想这就是所谓的“温故而知新”吧。

      下一篇笔记将重点讲述WW城中的战士－－action。不管哪一款网游中，战士永远是核心人物，最重要的部分，承担着最多最重要的任务，并且直接面对敌人。告诉大家如何实现WebWork中的action，以及实现过程中的相关问题和技巧。