关于web框架选择：WebWork和Tapestry

如果Tapestry5可以实现所宣讲的特性。
那么Tapestry的架构就可以比较完美。
想想看，不需要jsp，不需要标签，基本不需要js，去掉了烦多的xml配置文件，组件式，事件式，可以热发布，更快的速度。
基本上就是是纯粹的java代码＋html模板。还有比这更吸引人的么？

理想和现实肯定有差距的，想当初Tapestry3的描述就让我觉得很美，结果一个项目做下来磕磕碰碰，组件开发量和项目进度的权衡让人伤透脑筋。

组件化开发的正道是强大的IDE支持，否则是画饼充饥。

组件化开发我觉得并不需要IDE支持。我并不认为Tapestry4现在很好用。它优点很突出，缺点也是用。也是因为这个因素，估计Tapestry的作者才决定重新构建框架。从目前的资料来看，我觉得作者这样的思路是正确的。Tapestry5的框架应该是很不错的，至于实现的程度怎么样，现在还很难说。

至于IDE的支持我觉得并不重要。比如JSF，虽然很多IDE都支持得很好。但是用IDE拖拉开发出来的jsp源代码一定是惨不忍睹的，维护或者修改的人肯定很头痛。除错和性能肯定不好。从项目管理的的角度来讲代码也不好规范化。也不可能奢望程序员做出漂亮的jsp页面出来。
所以个人还是认为视图层就是应该纯粹的html模板。让美工去做漂亮的页面。让程序员写规范的java代码。

组件化的最大好处是开发效率，并不是优先考虑UI的美观，IDE的主要卖点之一也是开发效率，否则，也许UltraEdit会成为最好的开发工具了。

组件化可以提高开发效率当然，另外更重要的是技术的积累。
IDE的主要卖点之一也是开发效率对程序员来说当然是好事情。但从项目管理的规范化来说不一定很有用。
实际上IDE所实现的拖拉式的开发也不过是一些常见的web元素，比如输入框、下拉框、多选框等等。
如果项目一开始的时候，安排高级程序员做好常见所有UI的模板并制定页面的规范，程序员按照模板拷贝开发，效率一点也不会比使用IDE拖拉开发慢。更重要的是开发出来的视图层代码（比如jsp）组织是很规范的，非常容易读懂。这样可以对代码进行规范的管理。

用过T4之后才知道,有些东西只是看上去很美.
缺点只把感受较深的说说:1.稍微改变一个组件的功能就要自己写一个,并且即使直接拷贝或继承T4的组件也必须首先熟悉T4的内部运作方式,2.还有ASO和各种Page Begin/Load Interface及rewind,render的调用顺序和逻辑不能人为定制,3.继承的BasePage是Abstract类,不便于单元测试和跟踪Debug,4.ASO会在页面生成许多Serialize后的字符串,用户submit时要上传不少数据,在考虑怎样优化时也花了不少功夫,4.再加上hivemind这个很少在其他project中出现的IOC框架也需要花时间了解.
我认为任何一个MVC框架除了要结构合理,功能繁多之外,还有重要的一点是让程序员不用花大量时间深入的研究就能运用自如,毕竟我们也没指望一个框架能用十年.
所以除非你有很多的时间研究框架内部的运作,写出许多好用的组件,总结出一些最优化的方法,否则不建议用T4.
T4这类WEB组件开发方式的框架还是由微软来开发的好.

我也不建议现在转入Tapestry4。对Tapestry5有一定期望，但也要等Tapestry5出来以后才可以知道Tapestry架构是否可以更加完善、更加简单。
不过我更讨厌JSF，对struts2这种糊弄人的东西更加失望。WW没有用过，不过看了一些介绍也觉得没有多大新奇的地方。
也是这是因为java本身并不完美，更深一点来说是因为所有的技术都不完美，有不完美才会有技术的发展。所以所有的技术都不得不兼容以前的一些东西并且不断发展。可一旦发展到无法忍受之前技术的局限的阶段，就必须做彻底的变革。可是质变是量变的开始，新的一轮循环又开始了。

失落的世界，呵呵

我现在用springmvc..
Struts, Tapestry, webwork也都用过..
其实,不管用什么,只要能掌握精髓,熟悉并精通.
其实这些东西都差不多...

谢谢大家的回复。

项目最终技术架构是这样的：
后台使用Spring 2.0 + Hibernate 3，网站部分Web MVC使用WebWork 2.2；管理终端使用Rich Client实现，使用Eclipse RCP（有过一个项目开发经历）来开发，使用Spring HttpInvoker实现RCP同服务器端数据传输；使用ActiveMQ作为桌面客户端和后台服务器端数据同步、消息通知；