Laszlo：富客户端应用开发方案分析
2004年Laszlo Systems开放Laszlo Platform源代码，为J2EE开发者提供富客户端实现选择。Laszlo兼具以Flex和XUL/XAML为代表的两类实现策略的优势，J2EE开发者可自行开发界面。不过它存在脚本调试麻烦、运行效率和稳定性欠佳、对服务器硬件要求高等问题，目前更适合企业内部应用。
（本文发表于《程序员》杂志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则兼具了两者的优势。
上面是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平台”恐怕还为时过早。
扫一扫
228
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
