Result机制，让视图更丰富

struts2将result列为一个独立的层次，可以说是整个struts2的action层架构设计中的另外一个精华所在。result之所以成为一个层次，其实是为了解决mvc框架中，如何从control层转向view层这样一个问题而存在的。所以，接下来我们详细讨论一下result的方方面面。 

result的职责 

result作为一个独立的层次存在，必然有其存在的价值，它也必须完成它所在的层次的职责。result是为了解决如何从control层转向view层这样一个问题而存在的，那么result最大的职责，就是架起action到view的桥梁。具体来说，我把这些职责大概分成以下几个方面： 

封装跳转逻辑 

result的首要职责，是封装action层到view层的跳转逻辑。之前我们已经反复提到，struts2的action是一个与web容器无关的pojo。所以，在action执行完毕之后，框架需要把代码的执行权重新交还给web容器，并转向到相应的页面或者其他类型的view层。 

而这个跳转逻辑，就由result来完成。这样，好处也是显而易见的，对action屏蔽任何web容器的相关信息，使得每个层次更加清晰。 

view层的显示类型非常多，有最常见的jsp、当下非常流行的freemarker/velocity模板、redirect到一个新的地址、文本流、图片流、甚至是json对象等等。所以result层的独立存在，就能够对这些显示类型进行区分，并封装合理的跳转逻辑。 

以jsp转向为例，在struts2自带的servletdispatcherresult中就存在着核心的jsp跳转逻辑： 

httpservletrequest request = servletactioncontext.getrequest();  

requestdispatcher dispatcher = request.getrequestdispatcher(finallocation);  

....  

dispatcher.forward(request, response);  

再以redirect重定向为例，在struts2自带的servletredirectresult中，也同样存在着重定向的核心代码： 

httpservletresponse response = (httpservletresponse) ctx.get(servletactioncontext.http_response);  

response.sendredirect(finallocation);  

由此可见，绝大多数的result，都封装了与web容器相关的跳转逻辑，由于这些逻辑往往需要和servlet对象打交道，所以，遵循struts2的基本原则，将它作为一个独立的层次，从而将action从web容器中解放出来。 

准备显示数据 

之前提到，view层的展现方式很多，除了传统的jsp以外，还有类似freemarker/velocity这样的模板。根据模板显示的基本原理，需要将预先定义好的模板（template）和需要展示的数据（model）组织起来，交给模板引擎，才能够正确显示。而这部分工作，就由result层来完成。 

以struts2自带的freemarkerresult为例，在result中，就存在着为模板准备数据的逻辑代码： 

protected templatemodel createmodel() throws templatemodelexception {  

    servletcontext servletcontext = servletactioncontext.getservletcontext();  

    httpservletrequest request = servletactioncontext.getrequest();  

    httpservletresponse response = servletactioncontext.getresponse();  

    valuestack stack = servletactioncontext.getcontext().getvaluestack();  

    object action = null;  

    if(invocation!= null ) action = invocation.getaction(); //added for nullpointexception  

    return freemarkermanager.buildtemplatemodel(stack, action, servletcontext, request, response, wrapper);  

}  

有兴趣的读者可以顺着思路去看源码，看看这些result到底是如何获取各种对象的值的。 

控制输出行为 

有的时候，针对同一种类型的view展示，我们可能会有不同的输出行为。具体来说，可能有时候，我们需要对输出流指定特定的buffersize、encoding等等。result层，作为一个独立的层次，可以提供极大的扩展性，从而保证我们能够定义自己期望的输出类型。 

以struts2自带的httpheaderresult为例： 

public void execute(actioninvocation invocation) throws exception {  

    if (status != -1) {  

        response.setstatus(status);  

    }  

    if (headers != null) {  

        valuestack stack = actioncontext.getcontext().getvaluestack();  

        for (iterator iterator = headers.entryset().iterator();  

             iterator.hasnext();) {  

            map.entry entry = (map.entry) iterator.next();  

            string value = (string) entry.getvalue();  

            string finalvalue = parse ? textparseutil.translatevariables(value, stack) : value;  

            response.addheader((string) entry.getkey(), finalvalue);  

        }  

我们可以在这里添加我们自定义的内容到httpheader中去，从而控制http的输出。 

result的定义 

让我们来看看result的接口定义： 

public interface result extends serializable {  

    /** 

     * represents a generic interface for all action execution results, whether that be displaying a webpage, generating 

     * an email, sending a jms message, etc. 

     */  

    public void execute(actioninvocation invocation) throws exception;  

这个接口定义非常简单，通过传入actioninvocation，执行一段逻辑。我们来看看struts2针对这个接口实现的一个抽象类，它规定了许多默认实现： 

public abstract class strutsresultsupport implements result, strutsstatics {  

    private static final log _log = logfactory.getlog(strutsresultsupport.class);  

    /** the default parameter */  

    public static final string default_param = "location";  

    private boolean parse;  

    private boolean encode;  

    private string location;  

    private string lastfinallocation;  

    public strutsresultsupport() {  

        this(null, true, false);  

    public strutsresultsupport(string location) {  

        this(location, true, false);  

    public strutsresultsupport(string location, boolean parse, boolean encode) {  

        this.location = location;  

        this.parse = parse;  

        this.encode = encode;  

    // setter method 省略  

     * implementation of the <tt>execute</tt> method from the <tt>result</tt> interface. this will call 

     * the abstract method {@link #doexecute(string, actioninvocation)} after optionally evaluating the 

     * location as an ognl evaluation. 

     * 

     * @param invocation the execution state of the action. 

     * @throws exception if an error occurs while executing the result. 

    public void execute(actioninvocation invocation) throws exception {  

        lastfinallocation = conditionalparse(location, invocation);  

        doexecute(lastfinallocation, invocation);  

     * parses the parameter for ognl expressions against the valuestack 

     * @param param the parameter value 

     * @param invocation the action invocation instance 

     * @return the resulting string 

    protected string conditionalparse(string param, actioninvocation invocation) {  

        if (parse && param != null && invocation != null) {  

            return textparseutil.translatevariables(param, invocation.getstack(),  

                    new textparseutil.parsedvalueevaluator() {  

                        public object evaluate(object parsedvalue) {  

                            if (encode) {  

                                if (parsedvalue != null) {  

                                    try {  

                                        // use utf-8 as this is the recommended encoding by w3c to  

                                        // avoid incompatibilities.  

                                        return urlencoder.encode(parsedvalue.tostring(), "utf-8");  

                                    }  

                                    catch(unsupportedencodingexception e) {  

                                        _log.warn("error while trying to encode ["+parsedvalue+"]", e);  

                                }  

                            }  

                            return parsedvalue;  

                        }  

            });  

        } else {  

            return param;  

     * executes the result given a final location (jsp page, action, etc) and the action invocation 

     * (the state in which the action was executed). subclasses must implement this class to handle 

     * custom logic for result handling. 

     * @param finallocation the location (jsp page, action, etc) to go to. 

     * @param invocation    the execution state of the action. 

    protected abstract void doexecute(string finallocation, actioninvocation invocation) throws exception;  

很显然，这个默认实现是为那些类似jsp，freemarker或者redirect这样的页面跳转的result而准备的一个基类，它规定了result将要跳转到的具体页面的位置、是否需要解析参数，等等。 

如果我们试图编写自定义的result，我们可以实现result接口，并在struts.xml中进行声明： 

public class customerresult implements result {  

    // write your code here  

<result-type name="customerresult" class="com.javaeye.struts2.customerresult"/>  

常用的result 

接下来，大致介绍一下struts2内部已经实现的result，并看看他们是如何工作的。 

dispatcher 

<result-type name="dispatcher" class="org.apache.struts2.dispatcher.servletdispatcherresult" default="true"/>  

dispatcher主要用于返回jsp，html等以页面为基础view视图，这个也是struts2默认的result类型。 

在使用dispatcher时，唯一需要指定的，是jsp或者html页面的位置，这个位置将被用于定位返回的页面： 

<result name="success">/index.jsp</result>  

而struts2本身也没有对dispatcher做出什么特殊的处理，只是简单的使用servlet api进行forward。 

freemarker / velocity 

<result-type name="freemarker" class="org.apache.struts2.views.freemarker.freemarkerresult"/>  

<result-type name="velocity" class="org.apache.struts2.dispatcher.velocityresult"/>  

随着模板技术的越来越流行，使用freemarker或者velocity模板进行view层展示的开发者越来越多。struts2同样为模板作为result做出了支持。由于模板的显示需要模板（template）与数据（model）的紧密配合，所以在struts2中，这两个result的主要工作是为模板准备数据。 

以freemarker为例，我们来看看它是如何为模板准备数据的： 

public void doexecute(string location, actioninvocation invocation) throws ioexception, templateexception {  

    this.location = location;  

    this.invocation = invocation;  

    this.configuration = getconfiguration();  

    this.wrapper = getobjectwrapper();  

    // 获取模板的位置  

    if (!location.startswith("/")) {  

        actioncontext ctx = invocation.getinvocationcontext();  

        httpservletrequest req = (httpservletrequest) ctx.get(servletactioncontext.http_request);  

        string base = resourceutil.getresourcebase(req);  

        location = base + "/" + location;  

    // 得到模板  

    template template = configuration.gettemplate(location, deducelocale());  

    // 为模板准备数据  

    templatemodel model = createmodel();  

    // 根据模板和数据进行输出  

    // give subclasses a chance to hook into preprocessing  

    if (pretemplateprocess(template, model)) {  

        try {  

            // process the template  

            template.process(model, getwriter());  

        } finally {  

            // give subclasses a chance to hook into postprocessing  

            posttemplateprocess(template, model);  

从源码中，我们可以看到，createmodel()方法真正为模板准备需要显示的数据。而之前，我们已经看到过这个方法的源码，这个方法所准备的数据不仅包含valuestack中的数据，还包含了被封装过的httpservletrequest，httpsession等对象的数据。从而使得模板能够以它特定的语法输出这些数据。 

velocity的result也是类似，有兴趣的读者可以顺着思路继续深究源码。 

redirect 

<result-type name="chain" class="com.opensymphony.xwork2.actionchainresult"/>  

<result-type name="redirect" class="org.apache.struts2.dispatcher.servletredirectresult"/>  

<result-type name="redirectaction" class="org.apache.struts2.dispatcher.servletactionredirectresult"/>  

如果你在action执行完毕后，希望执行另一个action，有2种方式可供选择。一种是forward，另外一种是redirect。有关forward和redirect的区别，这里我就不再展开，这应该属于java程序员的基本知识。在struts2中，分别对应这两种方式的result，就是chain和redirect。 

先来谈谈redirect，既然是重定向，那么源地址与目标地址之间是2个不同的httpservletrequest。所以目标地址将无法通过valuestack等struts2的特性来获取源action中的数据。如果你需要对目标地址传递参数，那么需要在目标地址url或者配置文件中指出： 

<!--  

   the redirect-action url generated will be :  

   /genreport/generatereport.jsp?reporttype=pie&width=100&height=100  

   -->  

   <action name="gatherreportinfo" class="...">  

      <result name="showreportresult" type="redirect">  

         <param name="location">generatereport.jsp</param>  

         <param name="namespace">/genreport</param>  

         <param name="reporttype">pie</param>  

         <param name="width">${width}</param>  

         <param name="height">${height}</param>  

      </result>  

   </action>  

同时，redirect的result支持在配置文件中，读取并解析源action中valuestack的值，并成为参数传递到redirect的地址中。上面给出的例子中，width和height就是valuestack中的值。 

chain 

再来谈谈chain，之前提到，chain其实只是在一个action执行完毕之后，forward到另外一个action，所以他们之间是共享httpservletrequest的。在使用chain作为result时，往往会配合使用chaininginterceptor。有关chaininginterceptor，struts2的reference说明了其作用： 

struts2 reference 写道

if you need to copy the properties from your previous actions in the chain to the current action, you should apply the chaininginterceptor. the interceptor will copy the original parameters from the request, and the valuestack is passed in to the target action. the source action is remembered by the valuestack, allowing the target action to access the properties of the preceding action(s) using the valuestack, and also makes these properties available to the final result of the chain, such as the jsp or velocity page.

也就是说，chaininginterceptor的作用是在action直接传递数据。事实上，源action中valuestack的数据会被做一次copy，这样，2个action中的数据都在valuestack中，使得对于前台来说，通过valuestack来取数据，是透明而共享的。 

chain这个result有一些常用的使用情景，这点在struts2的reference中也有说明： 

one common use of action chaining is to provide lookup lists (like for a dropdown list of states). since these actions get put on the valuestack, their properties will be available in the view. this functionality can also be done using the actiontag to execute an action from the display page. 

比如说，一张页面中，你可能有许多数据要显示，而某些数据的获取方式可能被很多不同的页面共享（典型来说，“推荐文章”这个小栏目的数据获取，可能会被很多页面所共享）。这种情况下，可以把这部分逻辑抽取到一个独立action中，并使用chain，将这个action与主action串联起来。这样，最后到达页面的时候，页面始终可以得到每个action中的数据。 

不过chain这种result，是在使用时需要慎重考虑的一种result： 

as a rule, action chaining is not recommended. first explore other options, such as the redirect after post technique.

而struts2也做出了理由上的说明： 

experience shows that chaining should be used with care. if chaining is overused, an application can turn into "spaghetti code". actions should be treated as a transaction script, rather than as methods in a business facade. be sure to ask yourself why you need to chain from one action to another. is a navigational issue, or could the logic in action2 be pushed back to a support class or business facade so that action1 can call it too? 

ideally, action classes should be as short as possible. all the core logic should be pushed back to a support class or a business facade, so that actions only call methods. actions are best used as adapters, rather than as a class where coding logic is defined.

从实战上将，使用chain作为result也的确存在着上面所说的许多问题，我个人也是非常不推崇滥用这种result。尤其是，对于使用spring和hibernate的朋友来说，如果你开启opensessioninview模式，那么hibernate的session是跟随httpservletrequest的，所以session在整个action链中共享。这会为我们的编程带来极大的麻烦。因为我们知道hibernate的session会保留一份一级缓存，在action链中，共享一级缓存无疑会为你的调试工作带来很大的不方便。 

所以，谨慎使用chain作为你的result，应该成为一条最佳实践。 

stream 

<result-type name="stream" class="org.apache.struts2.dispatcher.streamresult"/>  

streamresult等价于在servlet中直接输出stream流。这种result被经常使用于输出图片、文档等二进制流到客户端。通过使用streamresult，我们只需要在action中准备好需要输出的inputstream即可。 

<result name="success" type="stream">  

  <param name="contenttype">image/jpeg</param>  

  <param name="inputname">imagestream</param>  

  <param name="contentdisposition">filename="document.pdf"</param>  

  <param name="buffersize">1024</param>  

</result>  

其他 

struts2的高度可扩展性保证了许多自定义的result可以通过插件的形式发布出来。比较著名的有jsonresult，jfreechartresult等等。有兴趣的读者可以在struts2的官方网站上找到它们，并选择合适的加入到你的项目中去。 

关于result配置简化的思考 

struts2的result，解决了“如何从control层转向view层”的问题。不过看了上面介绍的这些由框架本身实现的result，我们可以发现result所涉及到的，基本上还停留在为control层到view层搭建桥梁。 

传统的，我们需要通过配置文件，来指定action执行完毕之后，到底执行什么样的result。不过在这样一个到处呼吁简化配置的年代，存在着许多方式，可以省略配置： 

1. 使用annotation 

struts2的一些插件提供了@result和@results的annotation，可以通过annotation来省略xml配置。具体请参考相关的文档。 

2. codebehind插件 

struts2自带了一个codebehind插件（struts2.1以后被合并到了其他的插件中）。codebehind的基本思想是通过coc的方式，使用命名约定来确定jsp等资源文件的位置。它通过实现了xwork的unknownhandler接口，来实现当struts2框架无法找到相应的result时，如何进行处理的逻辑。具体文档可以参考： 

大家可以在上面这两种方式中任意选择，国内著名的开源倡导者springside也是采用了上述2种方法。在多数情况下，使用codebehind，针对其他的一些result使用annotation进行配置，这样可以在一定程度上简化配置。 

不过我本人对使用annotation简化配置的评价不高。因为实际上使用annotation，只是将原本就非常简单的配置，从xml文件中移动到java代码中而已。就代码量而言，本身并没有减少。 

在这里，我也在经常在思考，如何进行配置简化，可以不写annotation，完全使用coc的方式来指定result。codebehind在coc方面已经做出了榜样，只是codebehind无法判别result的类型，所以它只能支持dispatcher / freemarker / velocity这三种result。所以result的类型的判别，成为了阻碍简化其配置coc化的拦路虎。 

前一段时间，曾经热播一部电视剧《暗算》，其中的《看风》篇中数学家黄依依的一段话给了我灵感： 

黄依依 写道

开启密锁钥匙的复杂化，是现代密码发展的趋势。但这种复杂化却受到无线通讯本身的限制，尤其是距离远、布点多的呈放射性的无线通讯，一般的密钥总是要藏在报文中。

密钥既然可以藏在报文中，那么result的类型当然也能够藏在resultcode中。 

return "success";  

这样一个简单的success作为resultcode，是无法识别成复杂的result类型的，我们需要设计一套更加有效的resultcode，同时，struts2能够识别这些resultcode，并得到相应的result类型和result实例。这样，我们就可以借用codebehind的实现方式，实现xwork的unknownhandler接口，从而达到我们的目的。例如，我们规定resultcode的解析规则： 

success —— 使用codebehind的规则进行jsp，freemarker模板的寻址 

r:/user/list  —— 返回一个redirect的result，地址为/user/list 

c:/user/list —— 返回一个chain的result，地址为/user/list 

j:user —— 返回一个json的result，jsonresult的root对象为user 

s:inputstream-text/html —— 返回一个streamresult，使用inputstream，并将contenttype设置成text/html 

以此类推，大家可以定义自己喜欢的resultcode的格式，从而简化配置。有了这样的规则，也就有了后来的实现。具体解析这些resultcode，并为他们构建result实例的源码。

原文链接：[http://wely.iteye.com/blog/2295293]