（本文發表于《程序員》雜志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平臺”恐怕還為時過早。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=272258
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
