struts/tapestry/jsf是目前j2ee表现层新老组合的框架技术。从诞生时间上看，struts应该比较早，使用得非常广泛，tapestry  3.0逐渐引起广泛的重视，正当tapestry即将大显身手时期，sun推出jsf标准技术，虽然jsf一开始推出尚不成熟，留出了一段空白期，但是随着jsf1.1标准推出，jsf开始正面出击，粉面隆重登场了。  
　　其实，jsf和tapestry也并不是那种头碰头的相同竞争性技术，两者还是各有侧重点的，不过比较细微，但是这种细微点在实现一个大工程时可能带来不同的感受和变化。

　　首先，我们从一个高度来抽象一下表现层框架应有的技术架构，下图可以说所有表现层框架技术都必须实现的功能架构图：



　　当然，我们不必废话罗嗦mvc模式，mvc模式是基准模式，现在框架技术已经不必再拼是否是mvc模式了。  在上图mvc模式基础上，一个表现层框架无外乎要实现图中的三个功能：

　　1.在当前页面能够显示一个组件对象的内容；而不是象纯jsp那样，需要在jsp页面写入“调用对象方法”的java代码。

　　2.当用户按下页面的提交按扭或链接后，事件发生，这时应该触发服务器端并将当前页面的参数提交给服务器。这种机制表现在form表单提交和有参数的链接

　　3.从一个页面视图直接跳转到另外一个页面视图，单纯的导航作用。

　　我们通过下表来比较这  三种框架在实现上图各个功能时技术细节，从而得出他们的异同点和偏重点。

    struts  tapestry3.0  jsf  
在view显示的组件要求  组件必须继承actionform
  分显式调用和隐式调用
组件必须继承basecomponent  普通pojo
无需继承
managed  bean  
组件在view显示粒度  view页面只能显示与表单对应的actionform，配置中action  actionform  页面一般只能1:1:1关系。  可将组件嵌入页面任何一行，对使用组件数量无限制。  同tapestry  
页面分区tiles  使用tiles标签库实现，需要另外tiles-def.xml配置文件  组件有自己的视图页面，通过调用组件即直接实现多个页面组合。强大自然的页面组合是其特点。  通过组件+标签库实现subview,但如需重用layout,还要结合tiles.  
页面跳转  使用标签库html:link中写明目标url，url名称需要对照配置文件的path命名,与组件action耦合。  url名称是目标的组件名称，不涉及url和路径等操作，方便稳固。  类似struts，也需要在配置文件中查找,与组件分离。  
参数传递  使用html:link时传递参数超过一个以上处理麻烦。  直接调用组件，直接赋予参数，没有参数个数限制  参数分离传递给组件  
事件触发  通过表单提交submit激活，不能细化到表单里字段。  能够给于表单每个字段贴一个事件，事件组件必须实现pagelistener接口  同tapestry，事件组件必须实习actionlistener  接口  
  

　　struts组件编程模型

　　struts实现组件编程时有一些复杂：经常为一个页面中需要引入多个组件而头疼，因为struts中无法直接引入多个组件，必须绕一些圈子:

　　一般分两种情况：如果同一个action就可以对付这些组件，那么在这种情况下有两个办法：

　　1.将这多个组件装入一个actionform中，如使用mapform等机制；

　　2.手工将多个组件装入request/session等scope中，然后根据其名称在jsp中获得。

　　这两个方法都有缺点：  第一种办法经常一个actionform弄得面目全非，变成一个大杂烩，违反了oo分派封装的原则；第2种办法其实又回到jsp编程；

　　第二种情况，如果这些组件必须有预先由不同的action来处理，每个组件必须经过action  -->actionform流程，在这种情况下有两种办法：

　　1.使用tiles,  不同流程输出到同一个页面的不同区域。是一种并行处理方式。

　　2.  对多个流程首尾相连，第一action  forward结果是第二个action，最后输出一个jsp，在这个jsp中就可以使用前面多个流程的多个actionform了，这属于串行方式。

　　struts组件模型缺点

　　struts组件编程必须限定在action/actionform/jsp这三个框框中做文章，难度相对比较大，而tapestry/jsf则没有太多这些技术框框限制，两者在组件编程方面更让编程者自由一些，方便一些，这也是组件型框架的优势吧。

　　struts标签库

　　在struts中，经常需要使用标签库来显示组件actionform中内容，这就涉及到一个结合的问题，标签库是别人写的，参考struts的标签库用法，而组件是自己的，难度和麻烦就体现在这个结合点上。

　　jsf基本思路和struts差不多，只不过换了不同标签库，也需要标签库+组件的结合思考，不过因为组件这里是通用组件，没有什么限制，所以这样比struts要轻松一些。

　　tapestry使用了组件库概念替代了标签库，没有标签库概念，这样就没有标签库和自己的组件需要结合的问题，都是组件的使用，组件中分tapestry标准组件和自己定义的组件，这也是接触了jsp体系的人学习tapestry面临的一个思路转换。

　　具体以页面跳转为例子，页面跳转是靠链接  实现，链接是页面经常使用的元素。

　　struts提供的html:link在频繁使用就特别不方便，尤其在传递多个参数时：其中html:link的page值，是跳转对方页面或action的path，这个path一般需要到struts-config.xml查找action的相应path,一旦配置文件path值修改，涉及到这个所有相关页面都要修改。

　　jsf将链接概念划分两个方面：导航性质和事件激活，在导航方面还是需要到配置faces-config查询navigation的from-outcome的值。

　　由于tapestry没有标签库概念，只有组件或页面两个概念，因此，链接跳转目标要么是组件，要么是页面，简洁简单，它没有多余的path概念，就是组件名，也就是对象名称，组件名称和path名称合二为一。

　　总结

　　jsf在很大程度上类似struts，而不是类似tapestry，可以说是一种struts  2.0，都是采取标签库+组件的形式，只是jsf的组件概念没有象struts那样必须继承actionform的限制；jsf在事件粒度上要细腻，不象struts那样，一个表单一个事件，jsf可以细化到表单中的每个字段上。

　　jsf只有在组件和事件机制这个概念上类似tapestry，但是不似tapestry那样是一个完全组件的框架，所以，如果你做一个对页面要求灵活度相当高的系统，选用tapestry是第一考虑。

　　struts/jsf则适合在一般的数据页面录入的系统中，对于struts和jsf的选用，我目前个人观点是：如果你是一个新的系统，可以直接从jsf开始；如果你已经使用struts，不必转换，如果需要切换，可以将jsf和tapestry一起考虑。

　　另外，jsf/tapestry不只是支持html，也支持多种客户端语言如wml或xui等。

　　这三者之间关系：如果说struts是左派；那tapestry则是右派；而jsf则是中间派，中庸主义是sun联盟的一贯策略。

　　当然，你也可以发表你在实践中这三者任何一个的使用感受，以使得后来者有一个比较。