Tapestry,JSF和Struts的比较

Tapestry,JSF和Struts的比较

    这里我们要将 Tapestry 与其它主要的 Java Web 框架做一番比较，包括 Struts，JSF。

    Struts 是一个 Action 方式的 Web 框架，所有的请求直接对应了相应的 Action，我们需要通过一些相应的技巧性处理才能把我们在页面上的 Click，Value Change 等转换到后端对应的 Action，抽象程度显得不够高，并且这样会使 Struts 在处理一些较为复杂的页面时配置过多，造成开发和维护上的繁杂。另外 Struts 默认使用的 Tiles 模板框架使用了 <jsp:include> 方式的拼装页面技术，并且在每个页面都需要配置，这样的话，又增加了不少的配置量。在Struts中，经常需要使用标签库通过 EL（Expression Language）来显示组件ActionForm中内容，这就涉及到一个结合的问题，标签库是别人写的，而且 Struts 在这方面并没有确定的标准，如何才能让自己的组件库和现有的组件库很好的结合，难度和麻烦就体现在这个结合点上。

    JSF的视图层开发的基本思路和Struts差不多，只不过换了不同标签库，也需要标签库+组件的结合思考，不过因为组件这里是通用组件，没有什么限制，并且遵循了一个共同的标准，所以这样比Struts要轻松一些。JSF 提供了一套完整的生命周期和组件标准，我们很容易的为其定制一些组件和使用现有的组件库。另外JSF采用了事件驱动的方式，同一个页面对应的多个 Action 请求会比较直接的通过 EL映射到后端对应的 Java 方法上，从而大大减少了复杂页面的配置量。但是在默认情况下，JSF 每个页面的都需要配置其单独的导航，如果页面导航复杂的话，配置还是不少的。JSF 在默认情况下并没有集成模板引擎，但是开源的 Facelets 模板引擎提供了类似 Tapestry 的模板方式，从另外一种方式简化了 JSF 的开发。JSF 采用了 HTML 页面保存组件树的机制，页面的所有组件和组件状态被序列化到页面中或者 Session 中，这样的话，如果在页面上 Javascrīpt 通过修改 DOM 的方式修改页面的组件，会导致页面和组件树不一致，导致 JSF 无法正常工作，但是可以通过 Ajax 方式向服务端发出更新组件树的请求，但这样需要走完 JSF 整个生命周期，显得较为笨重，所以从架构上来看，JSF 在处理页面问题上不够灵活，也不够 Ajax 化。

    Tapestry使用了组件库的概念替代了标签库，没有标签库概念，这样就没有标签库和自己的组件需要结合的问题，都是组件的使用，组件中分Tapestry标准组件和自己定义的组件，这也是接触了JSP体系的人学习Tapestry面临的一个思路转换。这样极大的减小了页面修改而带来的修改难度。同为事件驱动的框架，在配置上 Tapestry 有着和 JSF 类似的优势，我们只需要简单的在 XML 文件里配置事件和后端方法的对应关系，或者使用 OGNL 直接在页面中与后端方法建立关联。在页面导航上，Tapestry 是根据监听器方法的返回值而确定，这样就省去了页面导航部分的配置。Tapestry 的模板技术天生就是其优势所在，这样的方式将前台页面的制作和后台业务系统的开发完美的结合在一起。Tapestry 因为没有 JSF 这样的组件树绑定的方式，就能够比较容易的和 Ajax 绑定在一起，目前开源的 Tacos 组件库就提供了很多这样的组件，并且整合了 Dojo Toolkit 使得我们开发页面中有了更多好用的组件，并且只需要很简单的配置工作就可以使用功能强大的 Web 组件和 Ajax 功能。

    另外，JSF/Tapestry不只是支持HTML，也支持多种客户端语言如WML或XUI等。