Tapestry的随想

Tapestry是从06年的时候就开始接触了，那个时候是3.0 ，现在是5.2，当时一起比较的还有wicket 给我的感觉就是wicket的学习曲线较低，而tapestry的比较难学。tapestry的难学主要体现在，1 他的事件回调太多，onPrepare,onPrepareRender,onPrepareSubmit
onBeginRender,是么时候调用什么函数必须记住，不然时间长了，你自己都忘了差不多了。
2他也并不是所见即所得的开发，所谓的美工将前端page写好后，后台程序员就可以通过t:type的方式去，注入tapestry的组件的想法是不成熟的，因为随着程序的深入，大部分的项目都需要通过template去reuse layout,这样一来浏览器就不知道怎么解析了。
3tapestry的组件开发比较麻烦。想要自定义form组件很难，在T5.0.15中img是无法被render成submit事件的，但是在5.1中却可以，曾经试图去重写 Submit组件的 beginRender 但是她的所有的方法都没有提供protected或者public的 关键字,这还算好的
要想定义一个复杂的组件，必须深入学习tapestry的组件内部逻辑，不知道这样的时间花在上面有没有意义因为4 tapestry的升级很麻烦，似乎tapestry的开发团队总是按照自己的想法去做事情，并没有考虑过如果从3.0升级到4.0需要付出什么代价，从4.0升级到5.0 几乎用了两个不同的框架，这一点对于一个连续开发的团队来说是致命的，因为知识点不能得到有效的积累，而且每一次升级都痛苦异常。

相比较wicket,他给我的感觉有点类似GWT,都是输入Swing类型的开发模式，但是一个是在java 一个是把java翻译成Javascript,GWT在这个上面给我的感觉更加友好，现在有了一个插件可以所见即所得的开发gwt应用，不知道用到detail的话会不会出问题，不过我使用GWT的经验告诉我，一个好的事件驱动型的框架，不在乎所见即所得的开发，而必须让开发人员能够用组件的思想去开发，或者说框架提供的API一定要让开发人员开发自定义组件方便快速，貌似GWT在这一点做的也不好，学习好GWT的关键就在于熟悉Javascript,不然的话，也只是用组件，自己不会开发组件等于0，我开发果一些GWT的组件，给我的感觉是很麻烦。

相比较事件驱动型的开发框架，MVC为什么长时间立于不败之地的关键就在于，他是一种很松散的架构。不管是准备数据的Model,还是数据展现的View，开发人员几乎可以用自己熟悉的任何技术去修改和变更，这个对于商业软件是很有好处的。既然连对象的重用在商业应用中都那么的复杂，那么复杂而庞大的组件库就跟不用说了。目前通过轻量级的MVC框架配合web 层的JS 库可以时间复杂而灵活的应用。似乎组件的重用，以另外一种方式转移到了客户端。有可能是未来web层的技术趋势。