Tapestry之我见

最近在研究Tapestry4，而Tapestry5也在如火如荼的开发中，年内应该就可以release了吧！
Tapestry5对整个架构完全重构，现在的tapestry5吸取了许多其他优秀项目的优点，包括RoR和google的guice。

看到过正面的评价，如：“apestry这样面向组件的web框架确实颠覆了我所有关于web框架的经验。 ”
当然也有反面的评价，如：“最讨厌代码和注释功能混在一起，从来不觉得这是进步”； “尽管不喜欢tapestry的page配置文件，然而更讨厌annotation的一窝蜂的乱用，把配置和代码逻辑写在一起一锅乱炖，想要改个验证条件还得重新写class文件。
HWL思路开发的tapestry框架最不好的地方就是无论模板、验证、IoC、各种页面组件、session管理、上传下载等什么都要自己作， 别人现成的优秀架构不容易集成进tapestry，开放型和交互性不好。我觉得tapestry里学了不白学的似乎只有ognl语言了，这个还不是HWL 开发的。
相比只下spring的开发思路就很好好，不要重复发明轮子，只考虑怎样更好的使用它。貌似T5里这种开发思路没有根本性的改变，打算从T4转到S2或WW，继续观望T5、T6。”

然而，有的时候就是需要重新发明轮子，正像如下所说：“现有的解决方案即使再不好，因为已经积累了大量的代码，开发效率仍然比从零开始的新的解决方案更高。如果我们只关注软件所能提供的商业价值，可能我 们永远都只会使用现成的东西，而不会另起炉灶做另外一套东西出来。以前 potian 批评 SAP 的设计已经落后了，与对象建模完全格格不入。这样的批评也许是正确的，但是想想看你如何才能积累到 SAP 这样的代码量？现在实现相同的业务是基于 SAP 更容易还是基于你们自己的 ERPTAO 更容易？万一是一种你们从来没有想到过的业务流程呢？

不过反过来说，如果大家都只从这个角度来考虑问题，那么技术就永远都不会发展了。而落后的架构从长远看所能提供的商业价值也是有限的。例如在 SAP 之上实现 OLAP 一类的分析的成本是非常高的，原因就是 SAP 的基础数据库设计完全没有考虑过分析型应用。所以我的朋友 xel 说：“有时候就是要重新发明轮子！”

总之，我认为Tapestry也许不是最顺畅的道路，但绝对是一个可取的道路。

让我们更自由的进行web开发吧。