关于web框架选择：WebWork和Tapestry

以前使用struts开发过一些小型的项目，然后开始接触webwork1.x并使用webwork1.x开发了两个小项目，最近一直在关注Tapestry项目，基本属于观察阶段，没有实战经验。

从strut过渡到webwork基本上感觉比较平稳，上手也快，有些概念彼此相通，对于tapestry现在只能说是门外汉，目前有一个项目，第一期大概2个月时间，以后估计需要后续开发半年时间完善，考虑到项目后期开发，所以前段时间一直计划时间tapestry开发，主要是欣赏tapestry组件开发方式，特别是可以使用现有的tapestry一些第三方开发的组件；

不过最近查阅了一些资料，发现有很多同学推荐webwork，robbin也是一位忠实的webwork用户(通过论坛帖子了解推测的)，这下子又开始摇摆了，到底选择哪个框架呢，请大家多提宝贵意见，谢谢。

补充一点：
后台使用spring+hibernate，并使用spring httpinvoker提供remote服务接口，并将网页上提交的数据实时同桌面客户端交换数据。


类似论题的一篇帖子：

http://www.iteye.com/post/133062

我是用过tapestry的，感觉不是很好用，比webwork差很多，不灵活，侵入性强，你必须按照它那套规范来，感觉不爽，而且感觉组件破坏了html结构

其实选择什么框架完全按照你的项目需求,和客户的要求,时间的多少.如果没有足够的时间去实践,还是用WEBWORK,毕竟引入一个没有实战过的框架,对项目还是有很大的危险性的.
从技术本身来讲,个人观点,WEBWORK

2个月的话还是用自己熟的把，tapestry只能说看上去很美，实际的学习曲线不低，最致命的是文档和论坛的支持都不够。楼上的一兄弟说的不灵活真是深的我心，有点特殊需求就要写个组件。没有长期奋战tapestry并致力于完善一整套自己组件库的计划的话，估计是感受不到“基于组件”开发的快感的。

今年带项目组用tapestry4开发两个系统。
感觉tapestry最大的有点是把web开发完全OO化了（struts只是把form封装成VO而已）。
举个例子说，比如一个用户管理功能通常包含查询、查看、新增、修改、删除等子功能。
在tapestry里面，用户管理可以抽象为一个类，查询、查看、新增、修改、删除这些功能都可以做为这个类的实例对象。
所以页面的调整在tapestry中九变成对象之间的调用关系。
页面的数据转换可以通过对象的方法来实现。比如查看中的ID如果想用名称来显示。
另外一点就是tapestry完全把视图和控制分离开了。用html模板来做视图输出。这点也是比较爽。可以抛弃掉jsp和那些讨厌的标签。

在2005年底的时候做过一些web框架的比较。
主要是struts、jsf、tapestry三种。
struts是比较陈旧了。实际上struts也可以实现组件式的开发，也可以实现基于事件的模式（需要结合js）；
jsf采用标签和组件结合的技术令人极端厌恶；java的一些所谓的标准往往都是几个大厂商争夺和妥协的产物，JSF也是这种怪胎也不奇怪；
最后选定tapestry。
不过事物都是两面性的。使用tapestry也有一些缺点，比如因为视图层只要html模板了，所以很多页面的规则和判断必须在控制层实现，会导致控制层代码的增加。另外，html模板对应种page配置文件也觉得很不爽。

个人比较看好Tapestry5。
大家可以到官方网站看看介绍
http://tapestry.apache.org/tapestry5/
变化很大。不过里面的很多新特性都让人觉得兴奋。
不过要注意一点是Tapestry5和Tapestry4是不兼容的。
所以建议大家现在不要做Tapestry4开发实际项目。
等Tapestry5出了再做考虑。
Tapestry5真实版本出来应该和struts2的时间查不多吧。又是一个争斗的时候了。

Tapestry 5 is an all new code base, written from the ground up to take Java web component development to new levels of productivity.

This new release removes many limitations of Tapestry 4:

Components no longer extend from base classes.
Components classes are no longer abstract. Components are pure, simple POJOs (plain old Java objects).
Tapestry no longer uses XML page and component specification files. Information that used to be supplied in such files is now supplied directly in the Java class, using Java annotations.
Changes to Tapestry component templates and classes are now picked up immediately, without any kind of restart. This will even work properly in production, not just during development.
Blazing Speed. The new code base operates considerably faster than Tapestry 4. Critical code paths have been simplified, and the use of reflection has been reduced or even eliminated. Tapestry 4 was as fast as an equivalent Servlet/JSP application, Tapestry 5 is much faster.

估计T5发布还需要一年左右时间，看了Tapestry Blog，发现对于T5的一些新特性是定下来了，但是具体如何实现这些新特性还在探讨中。