(本文发表于《程序员》杂志2005年第2期)
2004年10月,Laszlo Systems公司开放了主要产品Laszlo Platform的源代码,于是有意转向富客户端(rich client)的J2EE开发者们又多了一种选择。在Laszlo之外,rich client的实现策略大抵可以分为两类:以Flex为代表的一派采用独立于浏览器的展现格式(例如Flash),显示效果更美观,也不受浏览器局限,但表现层的开发需要专门技能,J2EE开发者常常不能胜任;以XUL/XAML为代表的一派则依赖于浏览器,开发者只需要编写类似于HTML的标记语言,但浏览器的兼容性则很差。Laszlo则兼具了两者的优势。
上面是Laszlo的应用架构图,看起来平淡无奇,任何一个基于Flash的rich client应用都有类似的架构。Laszlo的不同之处在于:在客户端运行的Flash界面不是由美工在Flash编辑器中制作出来的,而是在Laszlo表现服务器(Laszlo Presentation Server,LPS)中根据LZX文件编译生成、再发送到客户端的。LZX是一种界面描述格式,其中包含两部分内容:用于描述界面的XML标记,以及用于事件处理的JavaScript脚本。读者可能会说了:这样的格式不是就和传统的HTML页面很相似了么?正是如此。所以J2EE开发者自己也可以完成整个rich client界面的开发,不必去向美工学习Flash编辑器的用法了。
下面是一段典型的LZX代码。我们在<dataset>中描述一组来自服务器端的数据,随后的<text>标签就可以通过XPath定位到这些数据,并将它们以Flash的形式展现出来:
<canvas>
<dataset name="dset">
<employee>
<firstName>John</firstName>
<lastName>Smith</lastName>
<phone>617-536-7855</phone>
</employee>
</dataset>
<text datapath="dset:/employee/firstName/text()"/>
<text datapath="dset:/employee/lastName/text()"/>
<text datapath="dset:/employee/phone/text()"/>
<simplelayout axis="x"/>
</canvas>
为了迎合J2EE开发者的口味,Laszlo可谓用心良苦:不仅采用标准的XML作为界面描述和数据绑定格式,连事件处理机制都舍弃了Flash现成的ActionScript,转而采用程序员更熟悉的JavaScript。不过用XML描述界面的弊端也很明显,就是开发效率较低。针对这个问题,IBM也开源了一个基于Eclipse的编辑器插件,专门用于可视化开发Laszlo应用程序。读者可以在下列地址找到这个插件: http://alphaworks.ibm.com/tech/ide4laszlo。
可是,尽管具备了Flash美观、高度可移植的特点和XUL/XAML的简洁、易开发,但Laszlo仍然存在着诸多问题。首先,脚本的调试会是一件颇为麻烦的事情。虽然Laszlo提供了一个漂亮的脚本调试器,但由于LZX必须通过LPS的编译之后才能显示,因此整个调试过程必须连接在服务器上进行。当界面逻辑变得复杂时,可以预见脚本的调试过程将严重影响开发效率。其次,Laszlo的运行效率和稳定性都存在问题,尤其是在访问一个新界面时,编译Flash的过程长得足以吓跑用户,而且通过网络传输的数据量也偏大。最后,Laszlo对服务器硬件的要求相当高,在大负载环境下是否能保持稳定运行颇可怀疑。
综上所述,Laszlo确实为rich client应用开发提供了一种便利而具有高度可移植性的方案,但这种方案目前看来只适于开发企业内部应用。如果用来开发面向公网的应用,效率和传输数据量的问题可能变得非常严重。因此,将Laszlo称为“Rich Internet Application平台”恐怕还为时过早。
2004年10月,Laszlo Systems公司开放了主要产品Laszlo Platform的源代码,于是有意转向富客户端(rich client)的J2EE开发者们又多了一种选择。在Laszlo之外,rich client的实现策略大抵可以分为两类:以Flex为代表的一派采用独立于浏览器的展现格式(例如Flash),显示效果更美观,也不受浏览器局限,但表现层的开发需要专门技能,J2EE开发者常常不能胜任;以XUL/XAML为代表的一派则依赖于浏览器,开发者只需要编写类似于HTML的标记语言,但浏览器的兼容性则很差。Laszlo则兼具了两者的优势。
![](http://www.laszlosystems.com/lps-2.2/docs/guide/images/architecture-2.gif)
上面是Laszlo的应用架构图,看起来平淡无奇,任何一个基于Flash的rich client应用都有类似的架构。Laszlo的不同之处在于:在客户端运行的Flash界面不是由美工在Flash编辑器中制作出来的,而是在Laszlo表现服务器(Laszlo Presentation Server,LPS)中根据LZX文件编译生成、再发送到客户端的。LZX是一种界面描述格式,其中包含两部分内容:用于描述界面的XML标记,以及用于事件处理的JavaScript脚本。读者可能会说了:这样的格式不是就和传统的HTML页面很相似了么?正是如此。所以J2EE开发者自己也可以完成整个rich client界面的开发,不必去向美工学习Flash编辑器的用法了。
下面是一段典型的LZX代码。我们在<dataset>中描述一组来自服务器端的数据,随后的<text>标签就可以通过XPath定位到这些数据,并将它们以Flash的形式展现出来:
<canvas>
<dataset name="dset">
<employee>
<firstName>John</firstName>
<lastName>Smith</lastName>
<phone>617-536-7855</phone>
</employee>
</dataset>
<text datapath="dset:/employee/firstName/text()"/>
<text datapath="dset:/employee/lastName/text()"/>
<text datapath="dset:/employee/phone/text()"/>
<simplelayout axis="x"/>
</canvas>
为了迎合J2EE开发者的口味,Laszlo可谓用心良苦:不仅采用标准的XML作为界面描述和数据绑定格式,连事件处理机制都舍弃了Flash现成的ActionScript,转而采用程序员更熟悉的JavaScript。不过用XML描述界面的弊端也很明显,就是开发效率较低。针对这个问题,IBM也开源了一个基于Eclipse的编辑器插件,专门用于可视化开发Laszlo应用程序。读者可以在下列地址找到这个插件: http://alphaworks.ibm.com/tech/ide4laszlo。
可是,尽管具备了Flash美观、高度可移植的特点和XUL/XAML的简洁、易开发,但Laszlo仍然存在着诸多问题。首先,脚本的调试会是一件颇为麻烦的事情。虽然Laszlo提供了一个漂亮的脚本调试器,但由于LZX必须通过LPS的编译之后才能显示,因此整个调试过程必须连接在服务器上进行。当界面逻辑变得复杂时,可以预见脚本的调试过程将严重影响开发效率。其次,Laszlo的运行效率和稳定性都存在问题,尤其是在访问一个新界面时,编译Flash的过程长得足以吓跑用户,而且通过网络传输的数据量也偏大。最后,Laszlo对服务器硬件的要求相当高,在大负载环境下是否能保持稳定运行颇可怀疑。
综上所述,Laszlo确实为rich client应用开发提供了一种便利而具有高度可移植性的方案,但这种方案目前看来只适于开发企业内部应用。如果用来开发面向公网的应用,效率和传输数据量的问题可能变得非常严重。因此,将Laszlo称为“Rich Internet Application平台”恐怕还为时过早。