HTML、Swing還是XML，Java客戶端工具選擇？

2019-11-18 13:56:52

字體：大中小

供稿：網(wǎng)友

　　作者：jeru
email: [email protected]

[前言：] java軟件設(shè)計(jì)師和治理人員經(jīng)常會(huì)面臨這樣的難題：在開發(fā)應(yīng)用軟件的客戶端時(shí)，應(yīng)該在Swing、Html、xml三種技術(shù)中選擇誰。在這篇文章中，我將把自己在這三種技術(shù)方面的經(jīng)驗(yàn)與廣大讀者共享，并對在Java應(yīng)用軟件開發(fā)中選擇哪一種技術(shù)提出一些標(biāo)準(zhǔn)和技巧。在文章的最后，還會(huì)介紹一種整合Java Swing和HTML的新方法。

　　與現(xiàn)有的技術(shù)相比，Java有明顯的優(yōu)點(diǎn)，因此它已經(jīng)在服務(wù)器端應(yīng)用軟件的開發(fā)中確立了主導(dǎo)地位。然而，由于每一個(gè)應(yīng)用程序都有幾種形式的用戶界面和前端的表達(dá)形式，我們中的許多人都對在客戶端采用Java技術(shù)有不好的印象，因此在客戶端的開發(fā)中采用HTML似乎已經(jīng)成為唯一的選擇了。

　　實(shí)際情況是，在客戶端應(yīng)用程序的開發(fā)中不止只有HTML一種選擇，我們將在本文討論基于Java的應(yīng)用軟件開發(fā)中三種用戶界面的解決方案。我將首先討論HTML與jsp和servlet聯(lián)合使用的優(yōu)點(diǎn)和缺點(diǎn)，然后討論Java最初的目標(biāo)之一：通過GUI Applet實(shí)現(xiàn)交互式互聯(lián)網(wǎng)。最后，我們將討論XML以及由它所衍生出來的其他技術(shù)。

　　JSP/Servlets環(huán)境下的HTML客戶端

　　大多數(shù)讀者都曾編寫過servlet、開發(fā)過JSP應(yīng)用，清楚基于HTML的用戶界面的優(yōu)點(diǎn)和缺點(diǎn)。選擇HTML的最大的理由仍然是其廣泛的平臺(tái)適應(yīng)性，基本HTML的標(biāo)準(zhǔn)性很好，雖然比較枯燥，但它可以很好地完成工作。

　　由于HTTP/HTTPS協(xié)議非常簡單，可以使開發(fā)的應(yīng)用程序很好地適應(yīng)各種網(wǎng)絡(luò)配置和防火?。但這是有代價(jià)的，HTML缺乏與用戶的交互性，而且對用戶每個(gè)行為的響應(yīng)都需要與服務(wù)器進(jìn)行連接。作為一名編程人員，我們一直在追求簡單性，并使開發(fā)的軟件可以適合所有的瀏覽器？然而簡單性并不總是好的，簡單地說，與靜態(tài)HTML相比，javascript可以較好地實(shí)現(xiàn)不太復(fù)雜的交互性，但對于開發(fā)復(fù)雜的用戶界面而言，它還是不能勝任的。

　　除非擁有高速的互聯(lián)網(wǎng)連接，否則你一定有過焦慮的等待加載一個(gè)網(wǎng)頁的經(jīng)歷。盡管瘦客戶端提供了一些很好的非交互性的用戶界面，但傳統(tǒng)的胖客戶終端一般情況下都比它們更聰明。例如，Netscape Communicator和MS Outlook等電子郵件的前端就比基于互聯(lián)網(wǎng)的電子郵件工具具有更好的用戶親和性。

　　用Java開發(fā)一個(gè)HTML前端應(yīng)用是一個(gè)很好的選擇，因?yàn)镠TML提供了跨平臺(tái)的內(nèi)容傳輸能力。編程人員可以使用Java Servlets和JSP開發(fā)在任何操作系統(tǒng)平臺(tái)上運(yùn)行的服務(wù)器端應(yīng)用程序。同時(shí)考慮到眾多的Java API和它得到的廣泛的服務(wù)器開發(fā)商的支持，對于開發(fā)可伸縮互聯(lián)網(wǎng)站而言，Java是一種理想的選擇。

　　總而言之，配合使用Servlets和JSP的HTML前端開發(fā)工具是開發(fā)靜態(tài)界面的很好的方式，但當(dāng)需要對用戶的行為作出快速反應(yīng)和需要對數(shù)據(jù)進(jìn)行高速處理的復(fù)雜應(yīng)用時(shí)，這種方式則不大理想。

　基于Swing的GUI客戶端

　　今天還有多少人在使用Java Applet作為客戶端？也許使用基于HTML的UI更安全，但這是最好的選擇嗎？

　　AT&T的一個(gè)業(yè)務(wù)部門Telecorp PCS曾經(jīng)開發(fā)過一個(gè)應(yīng)用程序，使其商店可以收集希望購買移動(dòng)電話的用戶的資料，檢查其信用卡，然后立即開通移動(dòng)電話，除了確認(rèn)用戶輸入的信息外，應(yīng)用還必須通過使用排序、選擇和其他的標(biāo)準(zhǔn)數(shù)據(jù)庫功能處理提交的報(bào)告。此外，當(dāng)一個(gè)新的移動(dòng)電話開通后，這個(gè)應(yīng)用程序還需要顯示一個(gè)通知。

　　你能相像用HTML來完成這一切嗎？也許可能，但它將非常討厭，而且速度很慢，需要不間斷地使用網(wǎng)絡(luò)連接。Telecorp PCS決定冒險(xiǎn)在交互的Applet中使用Java，那么結(jié)果如何呢？完全成功，這一應(yīng)用程序在開發(fā)時(shí)采用了Swing，并布署在采用了Java插件的互聯(lián)網(wǎng)網(wǎng)站上。通過使用Swing UI類，很簡單地完成了應(yīng)用所要求的功能。

　　我相信許多開發(fā)人員在早期使用Java時(shí)，都使用過applet，并且在解決各種瀏覽器之間的不兼容性、applet下載時(shí)間、性能方面花費(fèi)過大量的時(shí)間。對客戶端Java最大的批評(píng)來自其對象性，但現(xiàn)在情況已經(jīng)有了很大的改觀。Sun已經(jīng)花費(fèi)了大量的時(shí)間來改進(jìn)其代碼的質(zhì)量，下面我將向你說明為什么基于Swing的UI是值得一試的。

　　Swing及其布署模式

　　我無需對Swing的內(nèi)部架構(gòu)以及類和界面的設(shè)計(jì)、設(shè)計(jì)模板的實(shí)現(xiàn)方面有多少新思想多作敘述了。Swing幾乎是我見過的最徹底的窗體系統(tǒng)，它的容器、組件和UI元素之間的關(guān)系非常清楚。Swing的架構(gòu)是基于Model-View-Controller（MVC）設(shè)計(jì)模板的，其數(shù)據(jù)與數(shù)據(jù)的表達(dá)和處理相互獨(dú)立。

　　大多數(shù)的Swing模型都是由各種UI元素共享的。例如，JTable使用和JList、JTree相同的模型集，這就使得學(xué)習(xí)和使用Swing非常簡單,而且Command、Observable和Listener等模板提供了很好的靈活性和良好的面向?qū)ο筇匦?。也許Swing架構(gòu)中唯一的不足之處是所有的事件都被交付到相同的EventDispatch線程中，使整個(gè)GUI客戶端應(yīng)用程序只有一個(gè)線程。但我們可以通過使用不同的線程響應(yīng)用戶的命令而不通過EventDispatch線程來完成所有操作，就可以很簡單地克服Swing這一缺點(diǎn)。

　　Sun發(fā)布的每個(gè)JDK版本都對Java和Swing的性能都進(jìn)行了改進(jìn)。JDK 1.3中與Swing相關(guān)的改進(jìn)表現(xiàn)在性能、內(nèi)存消耗和一個(gè)輸入確認(rèn)框架。性能和內(nèi)存消耗方面的改進(jìn)相當(dāng)可觀。我們公司將客戶端的應(yīng)用程序由JDK 1.2.2升級(jí)到1.3后，內(nèi)存消耗降低了30%，一些應(yīng)用程序內(nèi)存占用減少得更多。由于Swing內(nèi)部的初始化過程被優(yōu)化了，我們的客戶端應(yīng)用程序的運(yùn)行速度和響應(yīng)速度都更快了。簡而言之，對速度影響最大的是加載其他界面組件時(shí)自動(dòng)產(chǎn)生的大量的類，而這一方案中只包含有一個(gè)類。另一個(gè)重大的變化是缺省的JVM是HotSpot Client VM，它專門針對GUI繪制和客戶端應(yīng)用程序執(zhí)行進(jìn)行了優(yōu)化，可以通過在命令行方式下運(yùn)行java命令得到缺省的JVM。
　　
　　輸入確認(rèn)框可以使我們很方便地通過編程實(shí)現(xiàn)命令字段或輸入確認(rèn)。在這以前，假如要在處理下一個(gè)字段之前，對前一個(gè)用戶輸入進(jìn)行處理，必須在該部件上添加一個(gè)監(jiān)聽程序，每當(dāng)該部件不再是焦點(diǎn)后都需要對它進(jìn)行確認(rèn)，這種方式非常單調(diào)和乏味。使用新的InputVerifier類，可以通過創(chuàng)建InputVerifier子類的一個(gè)實(shí)例，并將它賦予需要確認(rèn)的JComponent，就能達(dá)到相同的目的。在焦點(diǎn)轉(zhuǎn)換之前，部件將自動(dòng)地調(diào)用verify()方法。

Swing存在的問題在于布署時(shí)的速度和兼容性問題?，F(xiàn)在，它的一個(gè)重大改進(jìn)解決了這些問題并使Java客戶端應(yīng)用程序重新成為一個(gè)可行的選擇，CPU的速度在過去2年中翻了一番。在JDK 1.3中，基于Swing的應(yīng)用程序的運(yùn)行速度已經(jīng)非?？炝?，所需要的內(nèi)存也相當(dāng)少。這就使我們在布署Swing方面還存在著最后一個(gè)問題，那就是如何進(jìn)行布署，在這里，我們有三種解決方案可供選擇。

　　方案一：Java插件

　　基于瀏覽器的Java中最出色的特性之一是Java插件。對HTML網(wǎng)頁作簡單的修改就能夠消除對瀏覽器JVM的依靠，并使我們可以在Sun的標(biāo)準(zhǔn)JVM中運(yùn)行Applet。一旦安裝了JRE，Applet就被下載到本地磁盤上，并被放置在高速緩沖區(qū)中，再打開帶Applet的HTML網(wǎng)頁的速度就會(huì)快許多，原因是所有的東西都是在本地磁盤上的。為說明其工作原理，我們首先來看看原來的Applet布署方式，HTML網(wǎng)頁是如何使用插件的，我們假設(shè)你已經(jīng)把握了HTML和Java Applet的有關(guān)知識(shí)，并創(chuàng)建了如下的網(wǎng)頁：

[TABLE][TR][TD][B]＜HTML＞
＜HEAD＞
＜TITLE＞My traditional applet page＜/TITLE＞
＜/HEAD＞
＜BODY＞
＜APPLET CODE=HelloWorld.class ARCHIVE=HelloWorld.jar＞
Sorry, looks like I bumped into another browser that doesn′t support Java applets
＜/APPLET＞
＜/BODY＞
[/B][/TD][/TR][/TABLE]
　　這種方式的缺點(diǎn)是它依靠瀏覽器JVM來加載和執(zhí)行HelloWorld類?？紤]到市場上存在有多種瀏覽器，它們執(zhí)行Java的方式各不相同，使得Applet的布署成為一件令人懼怕的事。你必須保證在經(jīng)過測試的JVM中運(yùn)行Applet。我們不要求瀏覽器運(yùn)行Java，而要求瀏覽器安裝和運(yùn)行我們將要在其中運(yùn)行Applet的JVM。在IE中，我們可以通過使用＜OBJECT＞標(biāo)志來完成這一任務(wù)，在其他的瀏覽器中，這一標(biāo)志可能會(huì)有所不同，例如在Netscape Navigator中是＜EMBED＞。修改后的網(wǎng)頁如下所示：

[TABLE][TR][TD][B]＜HTML＞
＜HEAD＞
＜TITLE＞My new applet page＜/TITLE＞
＜/HEAD＞
＜BODY＞
＜OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
width=100% height=100
codebase="./j2re-1_3_0_02-win.exe#Version=1,3,0,2"＞
＜param name="code" value="HelloWorld.class"＞
＜param name="archive" value="HelloWorld.jar"＞
＜param name="cache_archive" value="HelloWorld.jar"＞
＜param name="cache_option" value="Plugin"＞
＜/OBJECT＞
＜/BODY＞
[/B][/TD][/TR][/TABLE]
上面的網(wǎng)頁將使瀏覽器檢查指定ClassID的對象是否已經(jīng)安裝，假如沒有安裝，則從指定的URL下載JVM，并進(jìn)行安裝。然后瀏覽器執(zhí)行插件，并下載和顯示Applet。我們可以通過http://192.9.48.9/PRodUCts/plugin/1.3/demos/applets/GraphLayout/example1.html中的例子來學(xué)習(xí)其工作原理。關(guān)于Java插件更具體的資料請參閱Sun公司的網(wǎng)站。

　　插件帶來的好處是它可以支持各種操作平臺(tái)上的所有瀏覽器，此外，它還提供了一個(gè)有保障的執(zhí)行環(huán)境，插件只需要安裝一次，就可以對所有Applet進(jìn)行緩沖，使再次訪問網(wǎng)站時(shí)非常輕易。這一方法的一個(gè)最大不足之處是，在運(yùn)行Applet之前，必須下載一個(gè)大小為5MB的插件，這在低速的互聯(lián)網(wǎng)連接上尤其令人不能容忍。事實(shí)上，假如你的Applet只是一個(gè)大小為5KB的網(wǎng)頁頂端的一個(gè)鐘表，為此而下載一個(gè)5MB的插件是得不償失的。

　　方案二：使用Java Web Start

　　布署Java應(yīng)用軟件的另一種方式是Sun公司的Java Web Start，它在本質(zhì)上與Java插件相似，只是在第一個(gè)步驟上有明顯的不同。Java Web Start要求在每臺(tái)臺(tái)式機(jī)上進(jìn)行人工安裝，這一點(diǎn)遠(yuǎn)不如插件的自動(dòng)安裝。Java Web Start的安裝相當(dāng)簡單，一旦安裝完畢，依靠Java Web Start的應(yīng)用程序就可以被下載和安裝。就象插件一樣，應(yīng)用程序也是通過互聯(lián)網(wǎng)發(fā)行的。

　　根據(jù)我的經(jīng)驗(yàn)，Java插件在安裝上與Java Web Start相似，但比Java Web Start的用戶親和性更好，原因是它要求的治理員或用戶干預(yù)更少。也有一些公司創(chuàng)建了自己的功能類似的布署工具，這些工具有時(shí)候比Java Web Start還好用。例如，Sitraka公司的DeployDirector在性能上優(yōu)于Java Web Start，并且安裝也更簡單。

　　總而言之，通過使用Java插件和Java Web Start，基于Swing的應(yīng)用程序的布署比原來要簡單和安全許多，但仍然比點(diǎn)擊一個(gè)只有Javascript的HTML網(wǎng)頁要復(fù)雜得多。而且有些用戶可能對在本地機(jī)器上安裝JVM所需要完成的步驟有被脅迫的感覺，或者沒有發(fā)現(xiàn)Swing所帶來的好處，但假如需要一個(gè)動(dòng)態(tài)GUI用戶界面，使用戶享有更多地靈活性，沒有一種方法比采用Swing Applet更好了。

　　此外，假如整個(gè)開發(fā)都是基于Java的，在HTML請求數(shù)據(jù)和應(yīng)用程序內(nèi)部結(jié)構(gòu)之間就無需進(jìn)行映射。RMI可以提供快速的雙向網(wǎng)絡(luò)調(diào)用，它可以回叫客戶端應(yīng)用程序，提醒用戶根據(jù)服務(wù)器的要求更新顯示內(nèi)容。

　　方案三、以純HTML方式布署Java Swing

　　盡管HTML和Swing在開發(fā)客戶端應(yīng)用軟件方面各有利弊，但很明顯的是，理想的解決方案應(yīng)該是二者都支持。然而，由于這二種技術(shù)在本質(zhì)上具有較大的區(qū)別，在一個(gè)應(yīng)用程序中只能采用二者之一。盡管大多數(shù)用戶都會(huì)喜歡基于Swing的快速交互客戶端應(yīng)用程序，但下載并在客戶端系統(tǒng)上安裝JRE并非總是一個(gè)很好的選擇。有時(shí)候，安全和防火墻方面的限制使得RMI很難在網(wǎng)絡(luò)上運(yùn)行。在這種情況下，我們需要的是一種可以在所有系統(tǒng)上運(yùn)行的交互式客戶端應(yīng)用程序，即使我們能夠使用的客戶端應(yīng)用程序只有瀏覽器。CreamTec公司的WebCream可以充當(dāng)Swing-HTML之間的橋梁。

　　WebCream是一種Java工具，它可以為基于GUI的Java應(yīng)用程序和Applet提供自動(dòng)的互聯(lián)網(wǎng)訪問，可以使我們利用AWT和Swing實(shí)現(xiàn)GUI前端應(yīng)用程序，同時(shí)，可以自動(dòng)地使HTML訪問該應(yīng)用程序。在一定程度上，可以把WebCream看作是動(dòng)態(tài)的Java-to-HTML轉(zhuǎn)換工具，它可以即時(shí)地把Java中的框架和對話轉(zhuǎn)換為HTML。然后，將Webpage行為模擬為GUI事件，以保持應(yīng)用程序原有的邏輯。WebCream不要求對現(xiàn)有的表格和業(yè)務(wù)邏輯進(jìn)行修改，也無需學(xué)習(xí)任何新的API，它旨在發(fā)行現(xiàn)有的應(yīng)用程序和applets。WebCream只是設(shè)置互聯(lián)網(wǎng)服務(wù)器和描述應(yīng)用程序?qū)傩晕募墓ぞ?，它的?biāo)準(zhǔn)版具有全部的功能，而且是免費(fèi)的。WebCream還無需在客戶端的機(jī)器上進(jìn)行安裝，甚至無需瀏覽器支持Java，因?yàn)闉g覽器接收到的全部都是HTML代碼。

　　據(jù)所我知，只有WebCream才具有這樣的功能，沒有其他的工具可以提供相似的解決方案。但也有一些產(chǎn)品采用不同的方法使原本不是為互聯(lián)網(wǎng)設(shè)計(jì)的應(yīng)用程序具有互聯(lián)網(wǎng)訪問功能。windows 2000中有一種內(nèi)置的終端服務(wù)器（Terminal Server）服務(wù)，可以使用戶只要在本地系統(tǒng)登錄就可以通過遠(yuǎn)程方式訪問服務(wù)器。象Citrix系統(tǒng)公司的MetaFrame那樣，終端服務(wù)器向遠(yuǎn)程終端發(fā)送一個(gè)視頻流，并為在服務(wù)器上運(yùn)行的應(yīng)用程序模擬用戶的行為。它在高速網(wǎng)絡(luò)上可以很好地運(yùn)行，在低速網(wǎng)絡(luò)上的表現(xiàn)則不盡人意。它在Java應(yīng)用程序方面還有問題，因?yàn)樗鼈儾皇褂帽緳C(jī)的繪制和滾動(dòng)例程。終端服務(wù)器的可伸縮性還不太強(qiáng)，原因是每個(gè)用戶都在運(yùn)行它的一個(gè)拷貝。由WebCream轉(zhuǎn)換過的應(yīng)用程序在形式上與在本地系統(tǒng)上運(yùn)行的應(yīng)用程序有所不同，但它的性能更好，因?yàn)橹挥杏脩粼谔峤灰粋€(gè)頁面時(shí)，才會(huì)與服務(wù)器進(jìn)行連接。所有由具有WebCream功能的應(yīng)用程序服務(wù)的用戶可以共享一個(gè)JVM，因此也可以大大降低資源的消耗。

　　為了演示W(wǎng)ebCream的工作原理，下面的2個(gè)圖顯示了使用WebCream時(shí)，一個(gè)樣例GUI應(yīng)用程序在HTML前端應(yīng)用程序中是如何運(yùn)行的。圖1是一個(gè)正在運(yùn)行的GUI應(yīng)用程序（源代碼），圖2是WebCream治理著同一個(gè)應(yīng)用程序，窗口表示瀏覽器中的網(wǎng)頁。

　　Swing-HTML轉(zhuǎn)換方式并不適合所有的用戶，WebCream在一定程度上答應(yīng)通過HTML訪問前端應(yīng)用而提高基于Swing的前端應(yīng)用程序的價(jià)值。有95%的應(yīng)用程序可以無縫地轉(zhuǎn)換成HTML，另有5%的程序則需要改變數(shù)據(jù)的表達(dá)和處理方式。

基于XML/XSLT的客戶端應(yīng)用程序

　　在這里，我們假定你已經(jīng)對XML有了基本的理解，我將重點(diǎn)討論其前端應(yīng)用程序的開發(fā)。與XML相關(guān)的用戶界面開發(fā)的一個(gè)主要特征是內(nèi)容和表達(dá)方法之間互不干涉。簡單地說，就是數(shù)據(jù)被保存為XML文檔，而不再負(fù)責(zé)數(shù)據(jù)的使用和顯示，根據(jù)決定數(shù)據(jù)格式和在網(wǎng)頁上輸出方式的樣式表（XSLT）在HTML、WML、XHTML和其他表達(dá)形式中選擇一種數(shù)據(jù)表達(dá)形式。通過使各層之間保持相對的獨(dú)立，讓每個(gè)層處理各自的任務(wù)，這種方法的優(yōu)點(diǎn)是非常明顯的。

　　盡管XML提供了很好的數(shù)據(jù)發(fā)布模式，可以生成不同的表達(dá)模式，它仍然不能解決所有的問題。XML值得稱道的是讓開發(fā)人員專注于數(shù)據(jù)的處理，而讓設(shè)計(jì)人員和藝術(shù)家來處理數(shù)據(jù)的表達(dá)形式。應(yīng)用程序則把生成的XML文件保存在內(nèi)存或存儲(chǔ)在磁盤上，為得到指定的表達(dá)類型，例如HTML，可以通過適當(dāng)?shù)腦SLT類型表對內(nèi)容進(jìn)行轉(zhuǎn)換，該類型表可以將XML文檔轉(zhuǎn)換為HTML文檔。類型表與判定文檔中的內(nèi)容應(yīng)當(dāng)如何分布在網(wǎng)頁上的模板類似。它還可以轉(zhuǎn)換數(shù)據(jù)，執(zhí)行傳統(tǒng)的命令和循環(huán)來處理數(shù)據(jù)，進(jìn)行決策，因此它也可能變得非常復(fù)雜。

　　類型表的優(yōu)點(diǎn)之一是，假如要從一部移動(dòng)電話上訪問同一個(gè)應(yīng)用程序，所需要作的全部工作就是再創(chuàng)建一個(gè)新的WML類型表。從理論上說，這個(gè)應(yīng)用程序的所有其他部分都無需作任何改變，這使得服務(wù)器端的編程工作變得非常高效。采用XML實(shí)現(xiàn)一個(gè)前端應(yīng)用程序?qū)⑹挂恍┤蝿?wù)變得簡單，因?yàn)轱@示的數(shù)據(jù)和處理這些數(shù)據(jù)的代碼都無需改變。開發(fā)應(yīng)用程序各部分的開發(fā)小組可以獨(dú)立工作，從而加快開發(fā)進(jìn)程。

　　然而，我曾經(jīng)在基于XML的前端應(yīng)用程序開發(fā)中吃過苦頭，它的二個(gè)最主要的缺點(diǎn)是缺乏幫助生成XML以及類型表開發(fā)方面的工具和處理速度，第一個(gè)因素對那些使用Dreamweaver和FrontPage等可視化HTML開發(fā)工具創(chuàng)建HTML網(wǎng)頁的開發(fā)人員的影響更大。就我本人而言，我還是喜歡使用DreamWeaver，但我實(shí)在不能從在文本編輯器中編寫HTML代碼中得到什么樂趣。究竟，現(xiàn)在已經(jīng)是21世紀(jì)了，我們來看一個(gè)將XML文檔轉(zhuǎn)換為HTML的非常簡單的XSLT類型表：

＜?xml version="1.0"?＞
＜xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"＞

＜xsl:template match="page"＞
＜html＞

＜head＞
＜title＞＜xsl:value-of select="title"/＞＜/title＞
＜/head＞

＜body＞
＜xsl:apply-templates/＞
＜/body＞
＜/html＞
＜/xsl:template＞

＜xsl:template match="title"＞
＜h1＞＜xsl:apply-templates/＞＜/h1＞
＜/xsl:template＞

＜/xsl:stylesheet＞

　　假如所選的XSL類型表適當(dāng)?shù)脑?，上面的代碼會(huì)生成如下所示的HTML代碼：

＜html＞
＜head＞
＜title＞My first page＜/title＞
＜/head＞

＜body＞
＜h1＞Hello, world＜/h1＞
＜/body＞
＜/html＞

　　我們會(huì)發(fā)現(xiàn)，上面的代碼與我們用HTML開發(fā)工具得到的代碼不大相同。不幸地是，我們必須用手工的方式對它進(jìn)行編輯，在一個(gè)可以生成HTML文檔的工具中對它進(jìn)行處理后，然后在瀏覽器中打開生成的文檔。假如僅僅是為了美觀而改變字體的大小，那么就無需這么作了。

　　第二個(gè)問題是在運(yùn)行時(shí)完成所有的任務(wù)需要許多時(shí)間。假如數(shù)據(jù)格式不是XML，還需要生成XML文檔，在類型表對XML進(jìn)行轉(zhuǎn)換處理后，才能生成HTML代碼。與在Servlet或JSP應(yīng)用程序中向內(nèi)存緩存中寫文件相比，速度和簡潔性實(shí)在不是基于XML的前端應(yīng)用程序的優(yōu)點(diǎn)。

　　總而言之，假如需要?jiǎng)討B(tài)地生成不同版面和窗體的表達(dá)形式時(shí)，就需要使用XML。假如表達(dá)形式需要經(jīng)常變化或需要非常靈活，就應(yīng)該讓設(shè)計(jì)人員重新設(shè)計(jì)新的類型表。需要記信的是，設(shè)計(jì)人員只要把握XML和XSLT就萬事大吉了。

　　另一個(gè)需要使用基于XML的UI的場合是你需要處理的資料是XML文檔，而不是Java對象或關(guān)系數(shù)據(jù)庫。XML是一種在未來頗有前途的新技術(shù)，然而，目前使用JSP開發(fā)前端應(yīng)用不是比較方便的，尤其是HTML是唯一一種前端開發(fā)工具時(shí)更是如此。使用JavaBeans和JSP標(biāo)識(shí)庫等一些聞名的設(shè)計(jì)模式則能夠使數(shù)據(jù)的內(nèi)容和表達(dá)形式很好的分離。隨著自動(dòng)對XML/XSLT進(jìn)行編輯的工具的出現(xiàn)，這些技術(shù)在使用方面將更加簡單方便。

　　結(jié)論

　　具體到你自己的Java應(yīng)用程序，這三種前端技術(shù)各有利弊，任何一種技術(shù)都不能在所有方面超過其他二種。針對具體的應(yīng)用程序，我們必須對需求、用戶的期望進(jìn)行具體分析，對這三種技術(shù)進(jìn)行評(píng)估。下面是一些基本的準(zhǔn)則：

　　使用HTML/JSP：

　　　━━適合于由大量圖形和美術(shù)作品組成的靜態(tài)內(nèi)容。

　　　━━前端應(yīng)用程序的界面面向使用所有平臺(tái)的用戶。

　　　━━用戶所使用的互聯(lián)網(wǎng)連接較慢。

　　　━━希望快速地構(gòu)建功能比較單一的應(yīng)用程序。

　　使用Java Swing：

　　　━━適合創(chuàng)建具有內(nèi)置、與界面相關(guān)的邏輯的GUI。

　　　━━可以減輕網(wǎng)絡(luò)流量，提供盡可能的即時(shí)響應(yīng)。

　　　━━假如用戶對界面的質(zhì)量和功能有較高的期望。

　　　━━假如UI的功能比其美感更重要時(shí)。

　　使用XML/XSLT

　　　━━需要支持許多不同的而且經(jīng)常變化的窗體。

　　　━━數(shù)據(jù)是XML格式。

　　　━━需要個(gè)性化。

　　　━━計(jì)劃提供無線訪問等不同的訪問方式。

上一篇：J／Direct引出純Java問題

下一篇：DOM文檔操作和XML文件互相轉(zhuǎn)換的java實(shí)現(xiàn)