【Java EE 学习 69 上】【struts2】【paramsPrepareParamsStack拦截器栈解决model对象和属性赋值冲突问题】

昨天有同学问我问题，他告诉我他的Action中的一个属性明明提供了get/set方法，但是在方法中却获取不到表单中传递过来的值。代码如下（简化后的代码）

 public class UserAction implements modelDriven<User>(){
       private String name;
       private User model;
       public void setName(String name){
             this.name=name;
       }
       public String getName(){
             return this.name;
       }
       public User getModel(){
             this.model=model;
       }

       public String saveUser() throws Exception{
             System.out.println(this.name);//输出null
             System.out.println(this.model.getName());//正常输出表单中提交的值
             return "toUserInfoPage";
       };
 }

　　经过尝试，我们使用两种方法解决了这个问题，

　　　　1.将模型驱动接口直接去掉，这样在目标方法中直接使用System.out.pritln(this.name);可以正常获取到值

　　　　2.将拦截器栈改换成paramsPrepareParamsStack拦截器栈也可以解决掉这个问题，这个时候同时使用this.model和通过属性this.name都可以正常获取到值。

这只是尝试，但是到底为什么会这样我们也不清楚，但是肯定是默认拦截器和paramsPrepareParamsStack拦截器的差异造成的。

默认的拦截器栈：defaultStack

 <!-- A complete stack with all the common interceptors in place.
                  Generally, this stack should be the one you use, though it
                  may do more than you need. Also, the ordering can be
                  switched around (ex: if you wish to have your servlet-related
                  objects applied before prepare() is called, you'd need to move
                  servletConfig interceptor up.

                  This stack also excludes from the normal validation and workflow
                  the method names input, back, and cancel. These typically are
                  associated with requests that should not be validated.
                  -->
             <interceptor-stack name="defaultStack">
                 <interceptor-ref name="exception"/>
                 <interceptor-ref name="alias"/>
                 <interceptor-ref name="servletConfig"/>
                 <interceptor-ref name="i18n"/>
                 <interceptor-ref name="prepare"/>
                 <interceptor-ref name="chain"/>
                 <interceptor-ref name="debugging"/>
                 <interceptor-ref name="scopedModelDriven"/>
                 <interceptor-ref name="modelDriven"/>
                 <interceptor-ref name="fileUpload"/>
                 <interceptor-ref name="checkbox"/>
                 <interceptor-ref name="multiselect"/>
                 <interceptor-ref name="staticParams"/>
                 <interceptor-ref name="actionMappingParams"/>
                 <interceptor-ref name="params">
                   <param name="excludeParams">dojo\..*,^struts\..*</param>
                 </interceptor-ref>
                 <interceptor-ref name="conversionError"/>
                 <interceptor-ref name="validation">
                     <param name="excludeMethods">input,back,cancel,browse</param>
                 </interceptor-ref>
                 <interceptor-ref name="workflow">
                     <param name="excludeMethods">input,back,cancel,browse</param>
                 </interceptor-ref>
             </interceptor-stack>

paramsPrepareParamsStack拦截器栈：

 <!-- An example of the paramsPrepareParams trick. This stack
                  is exactly the same as the defaultStack, except that it
                  includes one extra interceptor before the prepare interceptor:
                  the params interceptor.

                  This is useful for when you wish to apply parameters directly
                  to an object that you wish to load externally (such as a DAO
                  or database or service layer), but can't load that object
                  until at least the ID parameter has been loaded. By loading
                  the parameters twice, you can retrieve the object in the
                  prepare() method, allowing the second params interceptor to
                  apply the values on the object. -->
             <interceptor-stack name="paramsPrepareParamsStack">
                 <interceptor-ref name="exception"/>
                 <interceptor-ref name="alias"/>
                 <interceptor-ref name="i18n"/>
                 <interceptor-ref name="checkbox"/>
                 <interceptor-ref name="multiselect"/>
                 <interceptor-ref name="params">
                     <param name="excludeParams">dojo\..*,^struts\..*</param>
                 </interceptor-ref>
                 <interceptor-ref name="servletConfig"/>
                 <interceptor-ref name="prepare"/>
                 <interceptor-ref name="chain"/>
                 <interceptor-ref name="modelDriven"/>
                 <interceptor-ref name="fileUpload"/>
                 <interceptor-ref name="staticParams"/>
                 <interceptor-ref name="actionMappingParams"/>
                 <interceptor-ref name="params">
                     <param name="excludeParams">dojo\..*,^struts\..*</param>
                 </interceptor-ref>
                 <interceptor-ref name="conversionError"/>
                 <interceptor-ref name="validation">
                     <param name="excludeMethods">input,back,cancel,browse</param>
                 </interceptor-ref>
                 <interceptor-ref name="workflow">
                     <param name="excludeMethods">input,back,cancel,browse</param>
                 </interceptor-ref>
             </interceptor-stack>

由于是paramsPrepareParamsStack拦截器栈解决了问题，所以这里着重看paramsPrepareParamsStack拦截器栈，亮点在前面的注释部分：

This stack is exactly the same as the defaultStack, except that it includes one extra interceptor before the prepare interceptor:the params interceptor.

　　这句英文意思简单明确，翻译过来大体意思就是paramsPrepareParamsStack拦截器栈和defaultStack拦截器栈相比只有一点不同：paramsPrepareParamsStack拦截器栈在prepare拦截器之前增加了params拦截器。

　　简单回顾一下struts2的工作流程，首先当一次Action请求发生的时候，首先在DefaultActionInvocation类中的init方法中会创建Action对象并压栈，接着会执行设置的拦截器栈，执行完毕所有的拦截器之后会执行Action中的目标方法，最后执行结果集。

　　这里获取参数的过程是在目标方法中完成的，这里获取不到参数是因为在拦截器栈中param拦截器的放置位置不对造成的，如果该拦截器放置到模型驱动拦截器之后则会发生以上问题的冲突；如果将该拦截器放置到模型驱动拦截器之前则不会发生上述的问题（模型驱动拦截器之后也放置相同的一个）

　　接着看paramsPrepareParamsStack拦截器栈前面的注释描述：

This is useful for when you wish to apply parameters directly  to an object that you wish to load externally (such as a DAO or database or service layer), but can't load that object until at least the ID parameter has been loaded. By loading the parameters twice, you can retrieve the object in the prepare() method, allowing the second params interceptor to  apply the values on the object. 

　　这段英文的意思并不难理解，翻译过来的意思就是：当你想给Action中的一个对象赋值的时候必须得获取该对象的唯一标识id，这样才能通过DAO层或者Service层或者查找数据库获取该对象，所以直到你能够获取到该id的值你都不能加载该对象；通过加载两次param拦截器，你能够在prepare方法中获取该对象，并且能够在第二个param拦截器中将所有的属性值赋值给该对象。

　　我觉得这段话漏掉了一个重要的拦截器说明，那就是模型驱动拦截器，模型驱动拦截器的作用只有一个：调用Action对象的getModel方法并将获取到的值压栈。然后在param拦截器中对getModel获取到的model对象属性赋值，参数值都是从前端页面中获取到的，比如表单或者Ajax请求等；这样在Action的目标方法中使用Model对象的时候就有值了;既然涉及到了prepare方法的问题了，那么肯定还关系到了PrepareInterceptor拦截器。

　　通过以上的分析，可以得到以下的工作流程：使用paramsPrepareParamsStack拦截器栈是有一定的时机的，使用paramsPrepareParamsStack拦截器的时候Action一定实现了接口Preparable（反之则不一定）,并且有prepare[[Do]MethodName]方法，实现的拦截器是PrepareInterceptor拦截器；为了使得PrepareInterceptor拦截器能够正常工作，ParametersInterceptor拦截器必须提供某些参数值（如id），这个时候就给Action中的属性赋值了；DefaultActionInvocation执行完成PrepareInterceptor拦截器之后（可能做一些赋值的工作，比如为Action中的对象属性赋值（利用ParametersInterceptor拦截器提供的参数值），之前的一个项目就使用这种方法解决了Action中的模型赋值的问题），执行到了ModelDrivenInterceptor拦截器，该拦截器将model对象压栈；接着又有一个ParametersInterceptor拦截器，该拦截器的作用不再是为Action中的属性赋值，而是为model对象中的属性赋值，执行完所有的拦截器之后会执行Action中的目标方法，最后执行结果集。

　　总的来说，虽然使用paramsPrepareParamsStack拦截器栈解决了之前的那个问题，但是该拦截器栈的设计本意并不是这样，Action中的属性赋值只是其作用中的一个环节，其余的需要使用PrepareInterceptor、ModelDrivenInterceptor以及后面的又一个ParametersInterceptor共同完成。

　　没想到一个莫名其妙的问题背后竟然有这么多奇妙的东西，看来还需要更加努力才行啊~