Java Web Framework综述

Java Web Framework综述
	发布者： 发布时间：2007-01-08
Java Web Framework综述 0.简介 本文介绍Java Web Framework的基本工作原理，和一些常用的开源Web MVC Framework(Struts, Web Work, Tapestry, Echo, JSF, Maverick, Spring MVC, Turbine, Cocoon, Barracuda)。 Web开发的最重要的基本功是HTTP；Java Web开发的最重要的基本功是Servlet Specification。HTTP和Servlet Specification对于Web Server和Web Framework的开发实现来说，是至关重要的协议规范。 应用和剖析开源Web Framework，既有助于深入掌握HTTP & Servlet Specification, 也有助于了解一些现代的B/S Web框架设计思想，如MVC，事件处理机制，页面组件，IoC，AOP等。在这个现代化的大潮中，即使Servlet规范本身也不能免俗，不断引入Filter、Listener等现代框架设计模式。同是Sun公司出品的JSF更是如此。 关于MVC模型、项目简介、配置文件、入门示例等基础知识，网上已经有大量的重复资料信息，本文不再赘述。 文中会提到一些相关的开源项目，和一些编程思想，如有需要，可以用相关的关键字在网上搜索，获取基本的背景知识。 本文力图言简意赅，突出重点。着重描述其他资料没有提到、或很少提到的较重要内容，如运行原理、主流用法，相关知识，关键特性等。 1. Java Web程序工作原理 Tomcat的Server.xml文件中定义了网络请求路径到主机本地文件路径的映射。比如， 我们来看一下，一个HTTP Request-Response Cycle的处理过程。 HTTP Request URL一般分为三段：host, context, path。 如这个URL，分为host=yourhost, context=yourapp, path=en/index.html三段。其中，Context部分由request.getContext()获得，path部分由request.getServletPath()获得（返回结果是“/en/index.html”）。 yourhost主机上运行的Tomcat Web Server接收到这个URL，根据Context定义，把yourapp这个网络路径映射为yourapp_dir/webapp，并在此目录下定位en/index.html这个文件，返回到客户端。 如果我们这个URL更换为，这个时候Tomcat会试图把yourapp_dir/webapp/en/index.jsp文件编译成Servlet，并调用运行这个Servlet。 我们再把这个URL更换为。 注意，戏剧化的事情就发生在这个时候，Servlet规范中最重要的类RequestDispatcher登场了。RequestDispatcher根据WEB-INF/web.xml配置文件的定义，调用对应的Servlet来处理en/index.do这个路径。 假设web.xml里面有这样的定义。 DispatchServlet yourapp.DispatchServlet DispatchServlet *.do 那么，RequestDispatcher会调用yourapp.DispatchServlet类处理这个路径。 如果web.xml没有定义对应en/index.do这个路径的Servlet，那么Tomcat返回“您请求的资源不存在”。 RequestDispatcher用于Web Server中，也可以用于应用程序中进行处理转向，资源定位。比如，我们在处理en/index.do的代码中调用， request.getRequestDispatcher(“cn/index.jsp”).forward(request, response), 就可以转交另外的资源cn/index.jsp来处理。 几乎所有的Web Framework都需要定义自己的Dispatch作用的Servlet，并调用RequestDispatcher进行转向处理。 阅读Web Framework源代码，有两条主要线索，(1)根据web.xml找到对应的Servlet类；(2)搜索包含“RequestDispatcher”词的代码文件。 我们看到，request, response 这两个参数，被RequestDispatcher在各种Servlet之间传来传去（JSP也是Servlet）。所以，request的setAttribute()和getAttribute()方法是Servlet之间传送数据的主要方式。 在MVC结构中，一般的处理流程如下： 处理HTTP Request的基本单位一般称为Action，是一个比Servlet轻量得多的接口定义，通常只有一两个方法，如execute(perform), validate等。 我们知道，URL->Servlet映射，定义在Web.xml配置文件里，但MVC框架通常会有另外一个定义URL-> Action映射的配置文件。 入口Dispatcher Servlet根据URL -> Action的映射关系，把请求转发给Action。 Action获得输入参数，调用商业逻辑，并把结果数据和View标识给（Model & View）返回给Dispatcher Servlet。 Dispatcher Servlet根据这个View 标识，定位相应的View Template Path，把处理转交给View（JSP +TagLib, Velocity, Free Marker, XSL等）。 View一般通过request.getAttribute()获得结果数据，并显示到客户端。至于是谁把结果数据设置到request.attribute里面，有两种可能：Action或Dispatcher Servlet。 2. Struts Struts是目前用户群最大、开发厂商支持最多的开源Web Framework。 Struts劳苦功高，为普及MVC框架作出了不可磨灭的贡献。显赫的声望，趋于老化的厚重结构，令Struts成为很多现代Web Framework参照、挑战的目标。 Struts应用主要包括3件事情: 配置struts-config.xml文件,实现Action类，实现View；还有一些高级扩展用法。下面分别讲述。 1. 配置struts-config.xml文件： Struts支持多级配置文件，具体用法和限制，详见Struts文档。这里只讨论struts-config.xml主流配置的内容。:-) (1) URL Path到Action的映射。 如 Struts的入口Servlet是ActionServlet。 ActionServlet需要此信息把URL Path调用对应的Action类处理。 在Struts运行期间，一个URL Path，只存在一个对应的Struts Action实例。所有的该URL Path的请求，都经过这同一个Struts Action实例处理。所以Struts Action必须线程安全。 想想看，其实这个要求并不过分，Action只是一个处理程序，不应该保存跨HTTP请求的状态数据，按理来说，也应该做成线程安全的。 (2) Template Name到View Template Path的映射。 Action类返回一个Template Name，ActionServlet根据这个Template Name获得对应的View Template Path，然后调用 request.getRequestDispatcher(“View Template Path”)，把处理转向路径对应的Servlet。在这个例子中，是转向/pages/Welcome.jsp编译后的Servlet。 我们来看一个一个Velocity的例子。 web.xml的定义如下 velocity org.apache.velocity.tools.view.servlet.VelocityViewServlet velocity *.vm 这时，request.getRequestDispatcher(“/pages/Welcome.vm”)会调用VelocityViewServlet，由VelocityViewServlet负责装并驱动运行/pages/Welcome.vm这个模板文件。 这里面有一个问题，如果调用的是DispatchRequester.include()方法，那么如何才能把pages/Welcome.vm传给VelocityViewServlet呢？ 如前所说，RequestDispatcher传递的参数只有两个，request和response。那么只能通过request attribute。正是为了解决这个问题，Servlet2.3规范之后，加入了javax.servlet.include.servlet_path这个属性。 参见VelocityViewServlet的代码（velocity-tool开源项目） // If we get here from RequestDispatcher.include(), getServletPath() // will return the original (wrong) URI requested. The following special // attribute holds the correct path. See section 8.3 of the Servlet // 2.3 specification. String path = (String)request.getAttribute("javax.servlet.include.servlet_path"); 从这里我们可以看出，为什么通晓Servlet Specification对于通晓Web Framework至关重要。 (3) Form Bean的定义 如 Struts Form Bean需要继承ActionForm类。 Form Bean类，主要有三个作用： [1]根据bean的定义，利用reflection机制，自动把request参数转化为需要的数据类型，填入到bean的属性当中。ActionForm类名中虽然有Form这个词，但不仅能够获取Form提交后的HTTP Post参数，也可以获取URL后缀的HTTP Get参数。 [2]输入验证。用户可以配置validation.xml，定义各属性的验证规则。 [3]当作View Object来用。用户需要熟练掌握Struts HTML TagLib的用法，才能把Form Bean的属性正确显示出来。 (4)其他定义。详见Struts文档。不再赘述。 2.实现Action。 Action类从Form Bean或直接从request中获得输入参数，调用商业逻辑，把结果数据（也许会包装成View Object），用request.setAttribute()放到request中，最后返回一个用ForwardMapping类包装的Template Name。 3.实现View。 Struts View的标准实现方法是JSP + Struts TagLib，其中最重要的就是Struts HTML TagLib。 html:form tag则是整个HTML Tag的核心，其它的如html:input, html:select等tag，都包含在html:form tag里面。 html:form tag用来映射Form Bean（也可以通过适当定义，映射其他的bean，但使用上会有很多麻烦）。html:form tag包含的其他Struts html tag用来映射Form Bean的属性。 Struts Bean TagLib的用法比较臃肿，一般情况下可以用JSTL代替。当然，如果需要用到bean:message tag实现国际化，那又另当别论。 Struts Tile TagLib用于页面布局。开源Portal项目Liferay使用了Struts Tile TagLib做为布局控制。 4.高级扩展用法 用户可以重载Struts的一些控制类，引入自己的一些定制类。详见Struts文档。 本文不是Struts专题，只讲述最重要的主流用法，其它边边角角的，不再赘述。 3. WebWork WebWork由于灵活的可插拔特性，受到很多资深程序员的欢迎。似乎很有可能大肆流行起来。 WebWork项目建立在XWork项目上。入口Servlet是WebWork项目中定义的ServletDispatcher，而Action在XWork项目中定义。 XWork Action接口的execute()方法没有参数，不像Struts Action那样接受request, response参数，所以XWork Action能够脱离Web环境被直接调用，便于单元测试。 这里引入了一个问题。没有了request参数，那么XWork Action如何获得request parameters作为输入数据？又通过什么桥梁（Struts用request.setAttribute）把结果数据传送到View层？ 在Web Work中，只能通过Action本身的getter, setter属性来传送输入参数和输出结果。 比如，我们有这样一个实现了XWork Action接口的类， YourAction implements Action{ int productId = null; String productName = null; public void setProductId(int productId){this.productId = productId;} public String getProductName(){return productName;} public String execute(){ productName = findNameById(productId); return “success”; } } 这个类里面的productId将接受request输入参数，productName是输出到页面显示的结果。 比如，这样的请求， Web Work会把1填到YourAction的productId里面，然后执行execute()方法，JSP里的语句会把YourAction的productName显示在页面上。 如果一个Web Framework采用了这种屏蔽Action的request, response参数的设计方式，一般也同时会采用这种Action和输入输出数据结合成一体的解决方式。类似的情形也存在于Tapestry和Maverick中，后面会讲到。 当WebWork ServletDispatcher接收到HTTP Request的时候，首先把所有相关的信息（包括request, response, session, servlet config, servelt context, 所有request参数）等存放到AcationContext中，然后根据Interceptor配置信息，生成一个YourAction的动态代理类对象。实际上运行的正是这个代理对象，如同Servlet Filter的工作机制一般，所有注入的Interceptor方法会先于Actio方法运行。 我们来看一下Action和Interceptor的地位：Action没有参数，无法获得ActionContext；而Interceptor接受的ActionInvoication参数拥有包括ActionContext在内的所有重要信息。 这种权力分配的不平等，注定了Action的作用非常有限，只限于调用商业逻辑，然后返回一个成功与否标志。所有与外部Web世界打交道、协调内部工作流程的重担，都责无旁贷地落在Interceptor的肩上。 我们可以设想一个极端的例子。我们声明一批不做任何事情的空Action，我们只是需要它们的空壳类名；我们制作一批对应的Interceptor，所有的转发控制、商业逻辑都在Interceptor上实现，然后把Interceptor都注入到对应的空Action。这在理论上是完全可行的。 在Web海洋的包围中，Action可少，Interceptor不可少。Action是一个孤岛,如果没有外来盟友Interceptor的协助，只能在自己的小范围内独立作战（比如Unit Test），而对整体大局的作战目标无法产生影响。 下面我们来看一下Action是如何在Interceptor的全程监管下工作的。 在WebWork中，我们需要如下配置XWork.xml。 YourAction.jsp webwork-default.xml里面的相关定义如下： 从上述的配置信息中可以看出，YourAction执行execute()方法的前后，会被 defaultStack所定义的三个Intercepter截获。这些Interceptor的任务之一就是把输入参数设置到Action的对应属性当中。 如果我们需要加入对YourAction的属性的验证功能，只要把上述定义中的validation Interceptor加入到defaultStack中就可以了。当然，实际工作还没有这么简单，一般来说，还要为每个进行属性验证的Action的都配置一份validation.xml。 XWork Interceptor能够在Package和Action级别上，进行截获处理。 Servlet Filter能够在URL Patten级别上，进行截获处理。虽然实际上，Servlet Filter截获的是Servlet，但某些情况下，可以达到和截获一批Action的同样效果。 比如，在Web Work中，我们可以为所有admin package的Action，加入一个Interceptor，当检查到当前Session的用户没有admin权限时，统一返回一个警告页面：您没有足够的权限执行这个操作。 我们看到也可以为所有URL Pattern为“admin/*.action”的URL定义一个Servlet Filter，当检查到当前Session的用户没有admin权限时，统一返回一个警告页面：您没有足够的权限执行这个操作。 WebWork的Interceptor配置是相当灵活的，相当于对Action实现了AOP。Interceptor相当于Aspect，基类AroundInterceptor的before(), after()方法相当于Advice。 另外，XWork也提供了从XML配置文件装配Component的机制，相当于实现了对于Component的IoC。 提到AOP和IoC，顺便多讲两句。Spring AOP能够截获所有Interface，不限于某个特定接口；Spring框架支持所有类型的IoC，不限于某种特定类型。 要知道，AOP, IoC可是现在最时髦的东西，一定不要错过啊。:D 相关概念导读（如果需要，请用如下关键字搜索网络）： AOP -- Aspect Oriented Programming -- 面向方面编程。 IoC – Inversion of Control --控制反转 Dynamic Proxy -- 动态代理，JDK1.4引入的特性。还可以进一步参考CGLib, ASM等开源项目。 WebWork直接支持所有主流View -- XSL,Velocity, FreeMarker,JSP。WebWork还提供了自己的TagLib。“直接支持”的意思是说，不用像Struts那样，使用Velocity的时候，还需要引入辅助桥梁Velocity-tool。 WebWork中用到一种功能和XPath类似的对象寻径语言ONGL，是一个开源项目。ONGL同样用在下面要介绍的Tapestry项目中。 Opensymphony下还有一个SiteMesh项目，通过Servlet Filter机制控制布局。可以和WebWork组合使用。 4. Tapestry Tapestry近来突然火了起来，令我感到吃惊。也许是JSF带来的Page Component风潮令人们开始关注和追逐Tapestry。 Tapestry的重要思想之一就是Page Component。 前面讲到，XWork能够自动把request参数映射到Action的属性当中。Tapestry走得更远，甚至能够根据request参数，映射到Action（Tapestry里面称为Page）的方法，并把request参数映射为Page方法需要的参数，进行正确的调用。就这样，Tapestry不仅把输入输出数据，而且把事件方法也绑定到了Page上面。 在Tapestry框架中，Action的概念已经非常模糊，而换成了Page的概念。而Tapestry Page是拥有属性和事件的页面组件，其中的事件处理部相当于Action的职责，而属性部分起着Model的作用。 除了使用Page和其它的Tapestry页面组件，用户也可以自定义页面组件。 这种页面组件/属性事件的编程模型，受到一些程序员的欢迎。当然，这种编程模型并不是没有代价的，每个Tapestry模板文件都需要一个对应的.page文件。这些.page文件定义了页面组件的属性、事件、Validator等信息。 我们来看一下B/S结构中，组件的属性、事件和HTTP Request绑定的基本原理。一个能够发出请求的页面组件（比如Link和Button），在输出自己的HTML的时候，需要输出一些特殊的信息来标志本组件的属性/事件，这样下次HTTP Request来的时候，会把这些信息带回来，以便Web Framework加以辨认识别，发给正确的Page Component处理。 这些特殊信息通常包含在URL参数或Hidden Input里面，必要的时候，还需要生成一些Java Script。Tapestry，Echo，JSF都是这种原理。 Tapestry的例子如下： JSF用TagLib实现页面组件，也提供了类似的CommandLink和CommandButton Tag。其中对应Tapestry listener的Tag属性是action。后面会讲解。 Tapestry的模板标签是HTML标签的扩展，具有良好的“所见即所得”特性，能够直接在浏览器中正确显示，这也是Tapestry的一个亮点。 5. Echo Echo提供了一套类似Swing的页面组件，直接生成HTML。 从程序员的角度看来，用Echo编写Web程序，和用Swing编写Applet一样，属于纯面向组件事件编程，编程模型也以Event/Listener结构为主体。 Echo没有Dispatcher Servlet，也没有定义URL->Action映射的配置文件。 Echo的Action就是实现了ActionListener接口（参数为ActionEvent）的Servlet（继承EchoServer类）。 所以，Echo直接由Web Server根据web.xml配置的URL -> Servlet的映射，进行转发控制。 Echo也没有明显的View层，Echo在页面组件方面走得更远，所有的HTML和JavaScript都由框架生成。你不必（也没有办法）写HTML，只需要（也只能）在Java代码中按照类似Swing编程方式，生成或操作用户界面。用户也可以定制自己的Echo组件。 Echo的UI Component的实现，采用了两个重要的模式。一个是Peer（Component -> ComponentPeer）模式，一个是UI Component -> Renderer模式。 虽然Echo的API更类似于Swing，但实现上却采用更接近于AWT的Peer模式。每个Component类（代表抽象的组件，比如Button），都有一个对应的ComponentPeer类（代表实际的组件，比如windows桌面的Button，Linux桌面的Button，HTML Button等）。 先别急，这个事情还没有完。虽然ComponentPeer落实到了具体的界面控件，但是它还是舍不得显示自己，进一步把显示工作交给一个Renderer来执行。 比如，在Echo里面，Button类对应一个ButtonUI（继承了ComponentPeer）类，而这个ButtonUI类会把最终显示交给ButtonRender来处理。 据说多了这么一步，能够让显示控制更加灵活丰富。比如，同一个Renderer可以处理不同的UI Component，同一个UI Component也可以交给不同的Renderer处理。 JSF的页面组件也采用了UI Component -> Renderer模式，后面会讲到。 6. JSF download source JSF的中心思想也是页面组件/属性事件。一般来说，JSF的页面组件是一个三件套{ UI Component, Tag, Renderer}。 UI Component有可能对应Model，Event，Listener。Tag包含componentType和rendererType两个属性，用来选择对应的的UI Component和Renderer。 JSF的应用核心无疑是JSF TagLib。JSF TagLib包含了对应所有重要HTML元素的Tag，而且Input Tag可以直接包含Validator Tag或者Validator属性，来定义验证手段。 我们通过JSF携带的cardemo例子，来看JSF的处理流程。 (1) carDetail.jsp有如下内容： 可以看到，这个button的submit action和carstore.buyCurrentCar方法绑定在一起。我们在Tapestry里面曾经看到过类似的情景。 (2) carstore在faces-config.cml中定义： carstore carstore.CarStore session (3) carstore.CarStore类中的buyCurrentCar方法如下： public String buyCurrentCar() { getCurrentModel().getCurrentPrice(); return "confirmChoices"; } (4) confirmChoices转向在faces-config.cml中定义： /carDetail.jsp Any action that returns "confirmChoices" on carDetail.jsp should cause navigation to confirmChoices.jsp confirmChoices /confirmChoices.jsp (5)于是转到页面confirmChoices.jsp。 除了Interceptor之外，JSF几乎包含了现代Web Framework应该具备的所有特性：页面组件，属性事件，IoC (ManagedBean)，Component -> Renderer，类似于Swing Component的Model-Event-Listener。 也许设计者认为，众多庞杂的模式能够保证JSF成为一个成功的框架。Portal开源项目eXo就是建立在JSF框架上。 可以看出这样一个趋势，现代Web Framework认为B/S结构的无状态特性和HTML界面是对编程来说是需要极力掩盖的一个缺陷，所以尽量模拟C/S结构的组件和事件机制，以吸引更多的程序员。 7. Maverick Maverick是一个轻量而完备的MVC Model 2框架。Maverick的Action不叫Action，直截了当的称作Controller。 Controller只接受一个ControllerContext参数。request，response, servlet config, servelt context等输入信息都包装在ControllerContext里面，而且Model也通过ControllerContext的model属性返回。整个编程结构清晰而明快，令人赞赏。 但这个世界上难有十全十美的事情，由于ControllerContext只有一个model属性可以传递数据，程序员必须把所有需要的数据都打包在一个对象里面设置到model属性里。这种麻烦自然而然会导致这样的可能用法，直接把Controller本身设置为model，这又回到了Controller(Action)和Model一体的老路。 前面讲到，WebWork也把所有的输入信息都包装在ActionContext里面，但Action并没有权力获取。而在Maverick中，Controller对于ControllerContext拥有全权的控制，两者地位不可同日而语。当然，由于参数ControllerContext包含request，reponse之类信息，这也意味着，Maverick Controller不能像WebWork Action那样脱离Web环境独立运行。 当然，这也并不意味着任何结构性缺陷。程序的结构由你自己控制，你完全可以把需要Unit Test的那部分从Web环境脱离开来，放到Business层。 如同WebWork，Maverick直接支持所有的主流View。Maverick的配置文件采Struts, Cocoon两家之长，URL -> Action -> View映射的主体结构类似于Struts，而View定义部分对Transform的支持则类似于Cocoon。如： 8. Spring MVC Spring MVC是我见过的结构最清晰的MVC Model 2实现。 Action不叫Action，准确地称做Controller；Controller接收request, response参数，干脆利落地返回ModelAndView（其中的Model不是Object类型，而是Map类型）。 其它的Web Framework中， Action返回值一般都只是一个View Name；Model则需要通过其它的途径（如request.attribute，Context参数，或Action本身的属性数据）传递上去。 Spring以一招IoC名满天下，其AOP也方兴未艾。“Spring出品，必属精品”的观念已经深入人心。我这里多说也无益，强烈建议读者去阅读Spring Doc & Sample & Code本身。 9. Turbine Turbine是一个提供了完善权限控制的坚实框架（Fulcrum子项目是其基石）。Turbine的个人用户不多，但不少公司用户选择Turbine作为框架，开发一些严肃的应用（我并没有说，用其它框架开发的应用就不严肃^_^）。Portal开源项目JetSpeed建立在Turbine上。 Turbine用RunData来传递输入输出数据。如同Maverick的ControllerContext，RunData是整个Turbine框架的数据交换中心。除了request, response等基本信息，RunData直接包括了User/ACL等权限控制相关的属性和方法，另外还包括Action Name和Target Template Name等定位属性。 Module是Turbine里面除了RunData之外的又一个核心类，是Turbine框架的基本构件，Action是Module，Screen也是Module。Turbine提供了LoginUser和LogoutUser两个Action作为整个系统的出入口。而其余流量的权限控制则由类似于Servlet Filter机制的Pipeline控制。 Turbine Pipeline的编程模型和Servlet Filter一模一样：Turbine Pipeline的Valve就相当于Servlet Filter，而ValveContext则相当于Filter Chain。还有更相近的例子，Tomcat源代码里面也有Valve和ValueContext两个类，不仅编程模型一样，而且名字也一样。 权限控制贯穿于Turbine框架的始终。要用好Turbine，首先要通晓子项目Fulcrum 的Security部分的权限实现模型。 Fulcrum Security的权限实体包括四个-- User, Group, Role, Permission。 实体之间包含{Role，Permission}和{ Group, User, Role}两组关系。 {Role，Permission}是多对多的关系，一个Role可以具有各种Permission；{ Group, User, Role}之间是多对多的关系，一个Group可包含多个User，并可以给User分配不同的Role。 权限模型的实现同样采用Peer模式，Entity -> EntityPeer, Entity -> ManagerPeer。 Entity和EntityManger代表抽象的模型概念，而EntityPeer和ManagerPeer代表具体的实现。 用户可以根据模型，提供不同的实现，比如，用内存结构中实现，用数据表结构实现，与Windows NT权限验证机制结合，与OSWorkflow的权限控制模型结合，等等。其中，用数据表结构实现，又可以选择用Torque实现，或者用Hibernate实现。（Torque是Turbine的O/R Mapping子项目） 例如，Falcrum.property配置文件包含如下Security相关选项： # ------------------------------------------------------------------- # S E C U R I T Y S E R V I C E # ------------------------------------------------------------------- services.SecurityService.user.class=org.apache.fulcrum.security.impl.db.entity.TurbineUser services.SecurityService.user.manager=org.apache.fulcrum.security.impl.db.DBUserManager services.SecurityService.secure.passwords.algorithm=SHA # ------------------------------------------------------------------- # D A T A B A S E S E R V I C E # ------------------------------------------------------------------- services.DatabaseService.database.newapp.driver=org.gjt.mm.mysql.Driver services.DatabaseService.database.newapp.url=jdbc:mysql://127.0.0.1/newapp services.DatabaseService.database.newapp.username=turbine services.DatabaseService.database.newapp.password=turbine 这说明，权限控制实现由数据库提供，需要根据权限模型创建如下数据表： TURBINE_USER，TURBINE_ROLE，TURBINE_GROUP， TURBINE_PERMISSION，TURBINE_ROLE_PERMISSION， TURBINE_USER_GROUP_ROLE。 10. Cocoon Cocoon项目是一个叫好不叫做的框架。采用XML + XSLT Pipeline机制，Java程序只需要输出XML数据，Cocoon框架调用XSL文件把XML数据转换成HTML、WML等文件。 Cocoon强大灵活的XSL Pipeline配置功能，XSLT的内容/显示分离的承诺，一直吸引了不少程序员fans。怎奈天不从人愿，由于复杂度、速度瓶颈、XSL学习难度等问题的限制，Cocoon一直主要限于网站发布出版领域，向CMS和Portal方向不断发展。另外，Cocoon开发了XSP脚本和Cocoon Form技术。 Cocoon的sitemap.xmap配置文件比较复杂，与其它的Web Framework差别很大。 主体Pipelines配置部分采用Pattern Match的方式，很像XSL语法，也可以类比于Web.xml里面Servlet Mapping的定义。比如，一个典型的URL->Action的映射定义看起来是这个样子： value="context://docs/department-form.xml"/> value="context://docs/department-form.xml"/> 11. Barracuda http://barracudamvc.org/Barracuda/index.html Barracuda是一个HTML DOM Component + Event/Listener结构的框架。 根据模板文件或配置文件生成静态Java类，并在代码中使用这些生成类，是Barracuda的一大特色。 Barracuda需要用XMLC项目把所有的HTML或WML模板文件，静态编译成DOM结构的Java类，作为页面组件。XMLC会根据HTML元素的id定义，生成相应DOM结点的简便操作方法。 Barracuda的事件类也需要用Barracuda Event Builder工具把event.xml编译成Java类，引入到工程中。Barracuda直接用Java类的继承关系映射事件之间的父子层次关系。比如，ChildEvent是ParentEvent的子类。 Barracuda的事件分为两类：Request Events（Control Events）和Response Events（View Events）。 Barracuda事件处理过程很像Windows系统消息队列的处理机制。 (1) Barracuda根据HTTP Request生成Request Event，放入到事件队列中。 (2) EventDispatcher检查事件队列是否为空，如果为空，结束。如果非空，按照先进先出的方式，从事件队列中取出一个事件，根据这个事件的类型，选择并调用最合适的EventListener，参数Event Context包含事件队列。 “根据事件类型，选择最合适的EventListener对象”的过程是这样的：比如， EventDispatcher从时间队列里取出来一个事件，类型是ChildEvent；Barracuda首先寻找注册了监听ChildEvent的EventListener，如果找不到，再上溯到ChildEvent的父类ParentEvent，看哪些EventListener对ParentEvent感兴趣。 详细过程参见Barracuda的DefaultEventDispatcher类。 (3) EventListener根据Event Context包含的request信息，调用商业逻辑，获得结果数据，然后根据不同情况，把新的事件加入到Event Context的事件队列中。 (4) 控制交还给EventDispatcher，回到第(2)步。 The End. Enjoy.
(转载文章请保留出处：
更多精彩文章:
最近评论:
Ray
fa1dd6c9ed749d82f01a62040a196c9d 69fae163d26a9b1682339a4eb6fc4ad9
Bilal
408b109d67d9af62a2526cded5db959e eb89aa2351bfb8dd061b0dc25061dcdb
Bret
b44a1aa3b0e4ac1ba45dddc578987239 1bb5907b91a875f331998f8e4f2b0572
Dana
e231339eaf521f3f70f2ed30bf322d8b musica per matrimonio emilia romagna abbandono scuola b8fb7d84153cc5c69600cbe1497734b2
Troy
2b468dc18155b7401fe9e42fcaccee18 b8a12f78e2ab8d9c8e5e94f78e975725
Justine
[url][/url] [url=]ea3681d685eddd735e6da9d4090e6ce4[/url] [u][/u] 8d1f2bfe3cbc5359328d95464cab8b7c
William
33d8054b672b5124fe8090a720649227 miur inail sicurezza scuola 8ea4fcdde1a965ef95e68187f350c6f6
Carey
85315cfc9307ffd0b509bccede602301 8cff813cd5cdf93d908a9e43c4704dad
Tre
[url][/url] [url=]ac1af2ce354be63b01ed5a96deab8f30[/url] [u][/u] 86b4eaaaf8201e29470f084ce1d2d695