Web 2.0 用戶界面技術
在用戶界面方面,當今的企業應用程序開發人員受到來自用戶和運營部門的雙重壓力。一方面,代表用戶的業務部門希望應用程序具有豐富的用戶界面,能夠最大限度地提高用戶的工作效率。他們希望所有應用程序都表現得像 Microsoft 的 Excel 或者其他客戶機應用程序一樣。希望應用程序能夠提供即時響應。
此外,若有相同數據的多個視圖(例如,一個表格視圖和一個圖形視圖),那么還希望在其中一個視圖中進行修改時,其他視圖能夠立即反映出這一修改。
另一方面,IT 運營部門喜歡純粹的基于服務器的交付模型。盡管他們知道 HTML 用戶體驗不如基于本機操作系統(OS)的用戶界面那么健壯,但他們認為為了改進用戶體驗,安裝、配置和管理客戶機代碼的成本太高了。
IT 組織中的許多人都親身體驗過 20 世紀 90 年代的客戶機/服務器部署模型,不愿意再重復那樣的經歷。實際上,如果有客戶機組件存在,許多 Java 2 Enterprise Edition(Java EE)應用程序可能不會構建起來,因為成本對于應用程序的業務目標來說太高了。服務器交付的部署模型為 IT 組織提供了低成本高效率的部署方式,這在 90 年代是 IT 組織的夢想。大多數組織都意識到了服務器部署的 Java EE 應用程序的經濟優勢,因此根本不會考慮部署那些必須在各個客戶機上進行安裝的代碼,除非是不得已。
那么,企業開發人員應該怎么做呢?用戶不希望由于幾秒的服務器響應時間而降低工作效率,而 IT 部門又不同意采用在客戶機上部署和管理代碼的老方法。如何能夠滿足這些表面上相互沖突的需求,讓雙方都滿意呢?
幸運的是,現有的技術使您能夠提供比瀏覽器更好的用戶體驗,同時不必在客戶機上手工安裝代碼。用這些技術構建的應用程序有時候被稱為 Web 2.0 應用程序。在 Tim O'Reilly 的文章 “What Is Web 2.0? Design Patterns and Business Models for the Next Generation of Software” 中,他指出:
我們正在進入一個前所未有的用戶界面革新時代,Web 開發人員最終能夠構建出與本地 PC 應用程序同樣豐富的 Web 應用程序。
Web 2.0 應用程序同時提供了兩種環境的優點:低成本高效率的基于服務器的部署模型,以及幾乎可以與客戶機應用程序媲美的用戶體驗。
對于為當今的 Java EE 應用程序提供豐富的用戶體驗,有幾種技術可供選擇:
1、Flex 和 OpenLaszlo
2、IBM® Workplace™ Managed Client 和 IBM Lotus® Expeditor
3、Faces Client Components
4、Ajax
5、HTML
Flex 和 OpenLaszlo
Flex 和 OpenLaszlo 是極其相似的聲明式方法,用來為 Java EE 應用程序創建比瀏覽器更好的用戶體驗。Flex 由 Adobe/Macromedia 提供,而 OpenLaszlo 是最初由 Laszlo Systems Inc 創建的開放源碼軟件。在這兩種環境中,都使用獨特的基于 XML 的語法來布置和創建用戶界面。
例如,為了在 Flex 中使用一個按鈕,可以用 MXML(Multimedia XML)編寫以下代碼:<a name="code-text"><mx:Button label="Submit"</mx:Button></a>
而對于 OpenLaszlo,可以用 LZX(LasZlo XML)編寫以下代碼:<a name="code-text"><button<Submit</ button></a>
為了允許不同的 UI 元素與服務器進行交互和通信,可以用 ActionScript(Flex)或 JavaScript(OpenLaszlo)編寫腳本。
盡管這兩種技術有許多相似性,但關鍵的一點差異是它們需要的運行時基礎設施。對于需要與服務器交換數據的客戶機,Flex 需要一個 Flex Data Services Server,它與 Flash Player 插件中運行的客戶機進行通信。在本質上,這個服務器為客戶機和應用程序的服務器組件之間的所有通信和數據交換提供中介。
OpenLaszlo 的最新版本做了一些運行時改進,使它對于開發人員更具吸引力。一項改進是版本 3 引入了一種 SOLO 開發模式,使得在某些部署配置中不再需要 Laszlo Presentation Server。另一個主要的改進是客戶機運行時環境。最新版本(OpenLazlo 4)正處于 beta 測試階段,它使基于 Laszlo 的應用程序能夠不帶 Adobe/Macromedia Flash Player 插件運行。許多公司不愿意被限制于某種專有的插件(比如 Flash Player),他們會歡迎這一改進。
如何判斷哪種產品更適合您的組織?Flex 的主要優點是可以從 Adobe/Macromedia 獲得充分的產品支持,但是要為 Flex Data Services Server 的許可證付費。對于某些公司來說,付出許可證費用來換取得到充分支持的產品是值得的。Adobe Flex 2 應用程序也需要 Flash Player plug-in V9。盡管 Flex 可以創建豐富的用戶體驗,但是某些公司不愿意承受費用和插件限制。
OpenLaszlo 技術最初是作為商業產品發布的,但是在 2004 年 Laszlo Systems 開放了這種技術的源碼,采用了 Common Public License(V1.0)許可方式。Laszlo Systems 提供支持訂閱,而且因為它是一個開放源碼項目,您可以選擇使用免費資源支持它。對于 OpenLaszlo,費用不是大問題,但是有些組織的公司策略不允許使用開放源碼軟件,所以可能不能選用 OpenLaszlo。
IBM Workplace Managed Client 和 Lotus Expeditor
IBM Workplace Managed Client 和 Lotus Expeditor 都是在開放源碼的 EclipseRPC 代碼基上構建的。EclipseRPC 這種技術源自 Eclipse 開發工具工作臺,這是由 eclipse.org 管理和控制的通用工具開發平臺。如果業務需要進行無連接操作,而且可以在客戶機上安裝組件,那么 Workplace Managed Client 和/或 Lotus Expeditor 是構建和部署應用程序的最佳技術。
IBM Workplace Managed Client 是 IBM 的 Workplace 產品系列的一個組件。它將各種協作服務組合在一個集成框架(或者說桌面環境)中。它提供的功能包括文檔管理、消息傳遞(包括即時消息傳遞)、Web 瀏覽、Notes® 7 的直接接口、eLearning、團隊空間、Web 會議以及一個用來跟蹤任務相關的線索的活動管理器。Lotus Expeditor 提供一個富客戶機平臺,它支持企業應用程序、事務處理、設備管理和 Web 服務。盡管選擇 Workplace Managed Client 或 Lotus Expeditor 都有不少合理的理由,但是如果應用程序在本質上是協作型的,那么 Workplace Managed Client 通常是最佳選擇。但是,如果應用程序在本質上是事務性的,那么通常建議選用 Lotus Expeditor。
Workplace Managed Client 和 Lotus Expeditor 都使開發人員能夠創建駐留在客戶機上的富客戶機應用程序,可以支持無連接操作。因為應用程序駐留在客戶機上,客戶機可以充分利用它所在工作站的功能,可以創建出高度交互性的用戶體驗。Eclipse 是 Workplace Managed Client 和 Lotus Expeditor 共同的基礎,它提供了一個獨立于操作系統的平臺,對開發人員隱藏了操作系統的細節差異,同時盡可能利用本機操作系統服務。因此,您可以開發一個 Java 代碼基,它能夠在 Linux™ 和 Windows™ 上運行,以后甚至能夠在 Macintosh 上運行。
為了利用這種技術,需要讓應用程序利用 Eclipse 插件體系結構。用戶界面組件是使用 SWT(Standard Widget Toolkit)部件或 jFace 組件構建的。SWT 是一個與本機窗口系統集成的部件集和圖形庫,但是使用獨立于操作系統的 API。jFace 是一個使用 SWT 實現的 UI 工具包,它簡化了許多常見的 UI 編程任務。jFace 在 API 和實現兩方面都獨立于窗口系統,其設計目的是使用 SWT 而不是隱藏它。最終結果是更具交互性的用戶體驗,其外觀和感覺與用戶熟悉的其他本機操作系統應用程序相似。
最后,“由服務器管理” 這一特性使基于 Workplace Managed Client 或 Lotus Expeditor 的應用程序有別于本機 Windows 應用程序。這項關鍵特性消除了與客戶機駐留的應用程序代碼相關聯的大多數(如果不是全部的話)系統管理成本。因此,部署應用程序的企業會獲得服務器部署的 Java EE 應用程序的所有成本優勢,同時用戶能夠享受操作系統特有的客戶機駐留的應用程序的用戶體驗;對于大多數組織,這都是雙贏的結果。
Faces Client Components
JavaServer Faces(JSF)是一種 Java EE 1.4 組件,最初是作為 JSR 127 開發的。這種技術的關鍵目標是,降低為 Java EE 應用程序開發用戶界面時要求 Java 開發人員具備的技能水平。因為 JSF 是一個框架,它提供了許多開箱即用的功能;在過去,開發人員在用 JavaServer Pages(JSP)構建同樣的用戶界面時需要手工編寫這些功能。
例如,假設您有一個大型 JDBC™ 結果集,需要將它向用戶顯示。JSF 框架提供了一個 DataTable 部件,可以用來顯示數據。如果使用簡單的 JSP 構建用戶界面,您就必須管理用戶與這個數據表的交互,并決定應該向用戶顯示哪些數據行。
通過使用 JSF DataTable,當用戶點擊 Next 來顯示表中的后 x 行數據時,JSF 框架將會處理 Next 請求,您不必自己編寫任何代碼。盡管 JSF 簡化了創建豐富的 HTML 用戶界面的過程,但是根據設計 JSF 是一種基于服務器的技術。對后 x 行數據的請求從瀏覽器發送到服務器,JSF 框架代碼在服務器上處理這個請求。JSF 需要一次到服務器的請求/響應往返。
為了改進基本的 JSF 部件,IBM 的 Rational® Application Developer V6 引入了 Faces Client Components。Faces Client Components 是 JavaServer Faces 技術的一種擴展,允許在客戶端執行某些 JSF 框架服務。例如,如果在上面的示例中使用 DataGrid Faces Client 組件,那么后 x 行數據的顯示就不需要到服務器的請求/響應往返。
對于 Rational Application Developer JSF 開發人員,使用 Faces Client Components 是自然的選擇。為了使用 Faces Client Components,要創建一個 Faces JSP 頁面并選擇 “Basic with client-side data caching ” 作為模型。當在 Rational Application Developer 中構造用戶界面時,只需從 Rational Application Developer 的工具面板中的 Faces Client Components 部分中選擇適當的 UI 控件。
在 Faces Client Component 的幕后發生了許多情況。會將 JSF 控件的 JavaScript 實現下載到瀏覽器中,并使用符合行業標準的 Service Data Objects 在瀏覽器和服務器之間進行通信。但是,這一切理所當然都是對用戶隱藏的;用戶只會注意到,與典
Ajax
Ajax(異步 JavaScript 和 XML)是 Jesse James Garrett 創造的一個術語,它是指一種基于標準的技術/設計模式,用來為服務器部署的應用程序開發比瀏覽器更好的用戶體驗。Ajax 對服務器技術沒有什么要求,可以處理 Java EE 應用程序、.Net 應用程序和其他應用程序。通過使用 Ajax,可以編寫 JavaScript 代碼來改進 HTML,創建出豐富的交互性用戶體驗。例如,JavaScript 可以執行本地用戶輸入驗證,為相同的數據提供不同的視圖(條形圖、表格、餅圖等等),或者通過瀏覽器的 XMLHTTPRequest 對象與應用程序的服務器組件進行異步的交互。
根據 Gartner Group 的 Hype Cycle for Emerging Technologies 2000 報告(2006 年 7 月 18 日),Ajax 已經達到了 “過度期望的頂峰”,“幻想” 已經開始成為現實了。看看書店里有那么多 Ajax 圖書,就能夠知道這股風潮有多么熱了。按照我的觀點,有三種東西幫助 Ajax 跨越了 Geoffrey Moore 指出的技術鴻溝:
1.現代瀏覽器。
在過去,編寫 JavaScript 的開發人員必須處理 Netscape、Internet Explorer 和其他瀏覽器之間的許多不兼容問題。在某些情況下,甚至同一種瀏覽器的不同版本也有不兼容問題。盡管仍然存在一些不兼容問題,但是大多數內部網應用程序通常需要 Internet Explorer 5.5 或更高版本和/或者 Firefox 1.0 或更高版本,在這些瀏覽器中以前存在的大多數不兼容問題已經被糾正了。近來組成了一個開放的行業協會 OpenAjax,它的目的是解決 Ajax 的不兼容性問題,以及解決其他 Ajax 相關問題。
2.Ajax 工具包。
在過去,希望使用 Ajax 的大多數開發人員實際上必須從頭開始,而 Ajax 工具包現在可以替他們完成許多繁重的工作。工具包提供了各種預制的基于 JavaScript 的用戶界面控件(部件),讓開發人員可以輕松地創建基于 Ajax 的用戶體驗。工具包通常還提供更高級的抽象,從而對開發人員隱藏前面提到的瀏覽器不兼容問題。
3.工具。
直到最近,大多數 JavaScript 開發人員實際上沒有開發工具來幫助簡化開發和調試。從 Firefox 瀏覽器發布開始,它就為 Ajax 開發人員提供了一些有用的插件,而且 IBM 最近在 Ajax Toolkit Framework 中集成了一系列有用的技術來幫助進行 Ajax 開發。ATF(Ajax Toolkit Framework)可以從 Apache 站點免費下載,它提供一個基于 Eclipse 的 Ajax 開發環境。ATF 提供的工具包括 JavaScript 語法敏感的編輯器、JavaScript 控制臺和 XMLHTTPRequest 對象查看器。ATF 還附帶三個預制的個性化組件:Dojo、Zimbra 和 Rico。
最后,按照我的觀點,當 Google 發布基于 Ajax 的 Google Maps 應用程序的 beta 版本時,Ajax 真正的轉折點到了。以前使用過地圖 Web 站點的任何人都會很快看出 Google 地圖軟件的優點。非技術人員感到吃驚,想知道 Google 是怎么做到的;而知道其原理的程序員開始注意到 Ajax,并開始考慮如何使用基于 Ajax 的技術改進自己應用程序的易用性和響應性。
純 HTML
盡管許多開發人員認為所有用戶像他們自己一樣,使用最新的 Firefox 瀏覽器并帶 10 個最流行的插件,但事實是許多機器仍然使用 Netscape 3.x 或 Internet Explorer 4.x 來訪問互聯網。使用這種水平的瀏覽器可能是為了使用某一應用程序(它的源代碼已經丟失了,無法修改了),或者是因為用戶非常保守,他們按照 “如果沒有出問題,就不必自找麻煩” 的原則來對待瀏覽器升級,所以仍然使用 Internet Explorer 4.0。
盡管 HTML 顯然不能提供其他技術可以提供的那么豐富的用戶體驗,但是基于 HTML 的用戶界面仍然會長期占據一定的地位。還沒有其他技術能夠像純 HTML 用戶界面一樣讓那么多用戶都能夠使用。因此,在未來的許多年內,許多應用程序仍然會提供這種用戶界面。
結束語
總的來說,當今業界的重要方向是改進服務器提交的應用程序的用戶體驗。Ajax 仍然還不太成熟,但是已經有了一定的實力,而且許多企業(包括小型和大型企業)已經開始在生產中使用它。本文提到的其他技術沒有得到這么大的關注,但是到目前為止還不能明確地說它們沒有前途。
還存在其他用戶界面技術,包括商業產品和開放源碼產品(比如 Nexaweb、Backbase 和 JackBE),但是由于篇幅限制本文沒有提到它們。關鍵一點是,這些技術都不是放之四海皆準的,所以沒有任何技術對于所有場景都是最佳選擇。這些技術都有各自的優點,都有其適合的場景。
那么,如何做出選擇呢?對于初學者來說,如果技術選擇背后的主要目標是接觸盡可能多的用戶,那么沒有任何技術能夠超越老式的 HTML。在另一個極端,如果您需要無連接操作,而且可以在用戶機器上安裝應用程序的組件,那么基于 EclipseRPC 的替代品之一(Workplace Managed Client 或者 Lotus Expeditor)是最佳選擇。
如果需要的豐富用戶體驗只能通過 Flash Player 來獲得,那么可能應該使用 Flex 或 OpenLaszlo。如果使用 JavaServer Faces 構建應用程序,那么使用一些 Faces Client Components 會更好。
最后,如果您的目標只是在現有的 HTML 用戶界面中增加一些易用性特性,或者是提供基于標準的插件免費的豐富用戶體驗,那么應該考慮使用 Ajax。按照目前的輿論,Ajax 似乎成了最流行的 Web 2.0 技術選擇,但是我不能肯定其他技術在成熟之后會不會取代它的地位。
選擇正確技術的關鍵是,讓應用程序的需求決定對用戶體驗技術的選擇。盡管這個建議似乎是理所當然的,但是在許多情況下開發人員所做的正好相反,他們被時髦的技術宣傳所蠱惑,做出 “技術驅動的選擇”,這常常導致許多困難的實現和部署問題,從而在開發項目時導致嚴重的延誤和問題。不要讓這種情況發生在您身上。
【編輯推薦】