OpenLaszlo 是否过气？

OpenLaszlo也算是个老家伙了吧

曾经很多人看好过OpenLaszlo，现在又有人看好ZK而抛弃了OpenLaszlo

我承认我是其中一个，作为FLEX的更开放版本OpenLaszlo，曾经有许多人为之赞叹

但是OpenLaszlo至今还有几个硬伤，妨碍了她的推广

稍稍列举以下

1. 没有与时俱进的IDE，有个很老版本的IDE，用起来有种想扁人的痛苦感。

　没有可视化IDE我其实可以接受，只要有个很好的文本IDE，不需要可视化(就像FREEMARKER)，但是仍然没有(或说与时俱进)

2. 没有很强大的LAYOUT,其实无论什么UI平台，最强大的LAYOUT无疑是GRIDLAYOUT(TABLELAYOUT)

   可以想象，如果HTML中没有TABLE会是什么样的一种情形。

　这个也很遗憾，仍然没有，倒是有些人自己写了几个，不过比起WINFORM/SWT/JFACE中的GRIDLAYOUT(TABLELAYOUT)就差了太多

  其实GRIDLAYOUT(TABLELAYOUT)如果做到灵活甚至智能，他的算法还是比较繁琐的，之前试着做个XUL的引擎的时候，曾经琢磨过

　如排版的智能化是一个很吸引人的东西，我觉得OpenLaszlo在这里是有些弱的。

3.不太支持组件动态创建，这个我不是很肯定，但我看遍了官方文档，几乎没有找到类似说明或例子

　这个其实也很重要，比如根据条件动态增删TABPANE的时候，或根据某些运行中的条件，生成或删除组件

　另外，也实际上使他不可能成为XUL引擎实现

4. 不支持AMF

  这个使OpenLaszlo失去了与ADOBE官方的FLEX在性能上竞争的机会。

5. 数据绑定很单一

　这个就是XML了，如果他象ADOBE官方的FLEX那样对JAVA对象的转换能更平滑一些就更好了。

　我认为这个可能和script有关，OpenLaszlo支持的javascript对对象转换还不够亲和。

 

我认为OpenLaszlo支持生成DHTML可能是一个方向性的错误，这可能导致了AMF的不支持，使他失去了一个提升性能的机会。

如果要DHTML我何必用OpenLaszlo呢，或者说，OpenLaszlo也许需要选择在某种情况下不支持DHTML以达到支持AMF。

 

不可否认，OpenLaszlo同时还有很多优点，如果你在应用中可以忽略这些缺点，可以把OpenLaszlo用在适当的地方取得不错的效果

可能由于小众的原因，OpenLaszlo生成的FLASH几乎是目前所有的反编译工具无法处理的，而ADOBE官方的FLEX编译的FLASH那实际上被反编译工具支持的太好了，而且由于RICH CLIENT的原因很多业务逻辑包括在其中，这个就很容易使得应用无法保密它理应保密的内部资料，算是一个塞翁失马的范例