Struts2/webwork与tapestry的差异（一）
用了webwork1.5年时间，也用了tapestry1年的时间，总结了一下他们之间的一些优点和缺点
一、从设计角度上说
tapestry是优秀的面向组件开发框架
webwork只是一个优秀的面向标签封装的开发框架
但虽然说是tapestry是面向组件开发的框架，当一个公司开发一套系统的时候，讲究的时间效率，上层管理才不管你是开发组件还是标签，他要的是的最快开发速度，前提是不出现bug，而往往一个功能最快的开发速度是使用通用的标签与简单的编码，而编写组件，说白了就是自定义标签，只不过这个标签的功能很大，封装了很多公用的业务代码，而这些东西不仅仅要有良好的设计方案以及明确的详细需求，还要熟练一个框架的基本原理加上编写组件消耗的开发时间，这样对很多人以及很多公司来说都是致命的，我也相信不会有多少公司会有专门的开发通用组件成员存在，何况tapestry也不是该公司自己研发的
但是面向组件的tapestry用了通用的组件对开发速度的提升不是webwork可替代的，并且已经明确了的组件又减少的bug的出现机率
以上可以说tapestry相对webwork更适应那些开发自身产品的公司
二、从资源管理角度上说
tapestry是单列模式的管理资源，是线程不安全的
webwork是线程安全
webwork对servlet的请求是通过比较上层的context进行读取的，这点tapestry是不可比拟的，这样tapestry在写业务方法的时候自然相对webwork而言方法一般都回很长，而且tapestry的action跳转控制里面是不应该定义内部成员，这样也会给开发带来一点的方便，而且阅读也不是很好，而且不熟悉tapestry的人进行开发就会出现一些意想不到的bug以及性能问题，我们公司就出现了这些问题，还好他们刚出现问题就聘请到了我=======满足一下自己的虚荣心
三、从读取数据角度上说
tapestry与webwork都是支持ognl标签
因此很多人说tapestry的jwcid标签简单而webwork的ww或者struts2的s 标签复杂难懂，其实他们是一样，不要因为改了名字就不认人了
四、从view层编写上说
tapestry是采用人们熟悉简单的html格式
webwork是采用java同志们熟悉的jsp格式
或许是html格式的原因的，很多人都说tapestry支持html，方便美工合作。其实我个人理解这是不对的，tapestry只是采用这种编写方法而已，最终还是跟jsp一样还是要生成servlet，但tapestry更优秀点地说他直接生成asci码的html，也正是这种asci码也造就了tapestry在某些方面就会出现一定的性能问题，如，当界面上需要显示大量的数据，如下拉框里放入俩百个对象，那么tapestry生成的asci码就会非常之大使得单个文件的html超过了80k=======80k都是个人感觉这个应该在http传输协议应该有影响，也希望会的人指教一下。所以过大的文件在b/s模式中是很影响效率的
然而webwork采用的是jsp，或许在很多人看来不方便工作合作，我倒是纳闷了，难道开发b/s模式采用java语言的人都不熟练jsp吗