本站不再更新,欢迎光临 java开发技术网
随笔-230  评论-230  文章-8  trackbacks-0

处理流程

1、在struts2中所有的请求由org.apache.struts2.dispatcher.FilterDispatcher传递过来。从请求的服务名解析出对应的action名称,并遍历HttpServletRequest、HttpSession、ServletContext 中的数据,并将其复制到Webwork的Map实现中,至此之后,所有数据操作均在此Map结构中进行,从而将内部结构与Servlet API相分离

2、以上述信息作为参数,调用ActionProxyFactory创建对应的ActionProxy实例。ActionProxyFactory 将根据Xwork 配置文件(xwork.xml)中的设定,创建ActionProxy实例,ActionProxy中包含了Action的配置信息(包括Action名称,对应实现类等等)。

3、ActionProxy创建对应的Action实例,并根据配置进行一系列的处理程序。包括执行相应的预处理程序(如通过Interceptor 将Map 中的请求数据转换为Action所需要的Java 输入数据对象等),以及对Action 运行结果进行后处理。ActionInvocation 是这一过程的调度者。而com.opensymphony.xwork.
DefaultActionInvocation 则是XWork 中对ActionInvocation 接口的标准实现,如
果有精力可以对此类进行仔细研读,掌握了这里面的玄机,相信XWork的引擎就不再神秘。

一段配置文件件及期解析

         < action  name ="login"  class ="one.LoginAction" >
            
< result  name ="success"  type ="dispatcher" >
                
< param  name ="location" > /main.jsp </ param >
            
</ result >
            
< result  name ="loginfail"  type ="dispatcher" >
                
< param  name ="location" > /login.jsp </ param >
            
</ result >
            
< interceptor-ref  name ="params"   />   <!--   参数拦截  -->
            
< interceptor-ref  name ="model-driven" /> <!--  模型驱动  -->
        
</ action >
include
通过include 节点,我们可以将其他配置文件导入到默认配置文件xwork.xml 中。从而实现良好的配置划分。这里我们导入了Webwork 提供的默认配置webwork-default.xml(位于webwork.jar 的根路径)。

package
XWork中,可以通过package对action进行分组。类似Java 中package和class的
关系。为可能出现的同名Action提供了命名空间上的隔离。
同时,package还支持继承关系。在这里的定义中,我们可以看到:
extends="webwork-default""webwork-default"是webwork-default.xml文件中定义的package,这里通过继承,"default" package 自动拥有"webwork-default" package 中的所有定义关系。这个特性为我们的配置带来了极大便利。在实际开发过程中,我们可以根据自身的应用特点,定义相应的package模板,并在各个项目中加以重用,无需再在重复繁琐的配置过程中消耗精力和时间。此外,我们还可以在Package节点中指定namespace,将我们的action分为若干个逻辑区间。如:<package name="default" namespace="/user"extends="webwork-default">就将此package中的action定义划归为/user 区间,之后在页面调用action的时候,我们需要用/user/login.action 作为form action 的属性值。其中的/user/就指定了此action的namespace,通过这样的机制,我们可以将系统内的action进行逻辑分类,从而使得各模块之间的划分更加清晰。
action
Action配置节点,这里可以设定Action的名称和对应实现类。
result
通过result 节点,可以定义Action 返回语义,即根据返回值,决定处理模式以及响应界面。这里,返回值"success"(Action 调用返回值为String 类型)对应的处理模式为"dispatcher"。
可选的处理模式还有:
1. dispatcher
本系统页面间转向。类似forward。
2. redirect
浏览器跳转。可转向其他系统页面。
3. chain
将处理结果转交给另外一个Action处理,以实现Action的链式处理。
4. velocity
将指定的velocity模板作为结果呈现界面。
5. xslt
将指定的XSLT 作为结果呈现界面。
随后的param节点则设定了相匹配的资源名称。
interceptor-ref
设定了施加于此Action的拦截器(interceptor)。关于拦截器,请参见稍后的“XWork拦截器体系”部分。interceptor-ref定义的是一个拦截器的应用,具体的拦截器设定,实际上是继承于webwork-default package,我们可以在webwork-default.xml 中找到对应的"params"和"model-driven"拦截器设置:
关于拦截器可以参考struts-default时的定义总之它就是把请求封装成对象,或把对象封装成。通常我们在<package>节点里包含这段代码,避免重复定义拦截.
<interceptors>
  
<interceptor-stack name="modelParamsStack">
    
<interceptor-ref name="params" />
    
<interceptor-ref name="model-driven" />
  
</interceptor-stack>
</interceptors>
然后在不同的Action节里点引用,方法如
<interceptor-ref name="modelParamsStack" />

Webwork 中的Model对象,扮演着承上启下的角色,它既是Action的输入参数,又包含了Action处理的结果数据。换句话说,输入的Http请求参数,将被存储在Model对象传递给Action进行处理,Action处理完毕之后,也将结果数据放置到Model 对象中,之后,Model 对象与返回界面融合生成最后的反馈页面。也正由于此,笔者建议在实际开发中采用Model-Driven 模式,而非Property-Driven 模式(见稍后“Action驱动模式”部分),这将使得业务逻辑更加清晰可读。

ActionContext为Action提供了与容器交互的途径。对于Web 应用而言,与容器的交互大多集中在Session、Parameter,通过ActionContext我们在代码中实现与Servlet API无关的容器交互。此外, 为了提供与Web 容器直接交互的可能。WebWork 还提供了一个ServletActionContext实现。它扩展了ActionContext,提供了直接面向Servlet API的容器访问机制。

我们可以直接通过ServletActionContext.getRequest 得到当前HttpServletRequest 对象的引用,从而直接与Web 容器交互。
posted on 2007-03-21 14:59 有猫相伴的日子 阅读(1166) 评论(0)  编辑  收藏 所属分类: j2ee

只有注册用户登录后才能发表评论。


网站导航:
 
本站不再更新,欢迎光临 java开发技术网