Tapestry的随想

公良光熙
2023-12-01
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层的技术趋势。
 类似资料: