Sealyu

Google Web工具包（GWT）確實是使用Java開發(fā)Ajax應用的一種誘人方法。如果你在AWT/Swing/SWT和服務器小程序方面有著扎實背景，實際上很容易學會使用GWT，但如果要做的不僅僅是快速原型設計，那么某些難題仍然存在。

忠告之一: 分而治之

眾所周知，GWT應用就是Java應用。不過，問題在于是“哪種Java”，我們需要牢記: GWT編譯的是與J2SE 1.4.2或者更早版本兼容的Java源代碼。另外，只有J2SE 1.4.2 API的子集得到支持，即java.lang和java.util程序包。即便在使用這些程序包時，也要非常認真地研究Google在運行庫支持方面的注 釋，并且牢記相應的忠告: 如果確保從一開始就只使用客戶端代碼中的可轉換類，那么就可以避免許多問題。為了及早發(fā)現(xiàn)問題，只要在宿主模式（hosted mode）下運行，就要對照JRE仿真庫檢驗代碼。因而，第一次運行應用時，就會發(fā)現(xiàn)大部分不支持的庫。所以，要及早并且經(jīng)常運行。

現(xiàn)在，筆者給出的忠告就是“分而治之”，具體意思就是一開始就把應用代碼分成三個不同的部分: 客戶端代碼、RPC相關代碼和服務器端代碼，然后構建相應的Eclipse項目，從而完成任務。這樣一來，就可以利用不同的Java語言版本，用于客戶端 和服務器部分。筆者用Java 5構建了應用的服務器部分（服務器小程序代碼）; 但如果使用Mustang版本，那么在本文的代碼片段中（由于篇幅有限，本文所涉及的程序代碼可通過以下鏈接查詢: http://blog.ccw.com.cn/article-htm-itemid-17924-type-blog.html），可以用Java 6取代Java 5。即便在服務器端仍然使用J2SE 1.4.2，這種分治法也可以在將來提供更大的靈活性，明確分離代碼（“分離問題”），而不會在GWT宿主模式下限制調試操作。如果所有部分都在一個 Eclipse項目中，則需要非常嚴謹，特別是在服務器端上; 不然，就會出現(xiàn)編譯或者運行問題。

需要使用特殊的命名約定，這樣可以清楚確認不同項目，并且簡化部署腳本。可以使用譬如名為GWT-< ModuleName>的Eclipse工作集來包括所有三個項目。這里，“ModuleName”是識別Web應用的GWT模塊的名稱。

● 客戶端代碼: 包含與用戶界面相關的代碼，可以轉換成JavaScript。因此，局限于J2SE 1.4.2和GWT運行時支持。啟用每個項目的Eclipse Java編譯器設置和“Java編譯器錯誤/警告”，把Java依從級別調整到1.4、把源代碼和類文件兼容性調整到1.4（假設不是使用1.4之前的 JDK版本）。該項目的名稱是< ModuleName>-client，譬如“JUnit2MR-client”，它依賴于構建路徑設置中的< ModuleName>-rpc項目。程序包名稱類似< com.company.project>.gwt.< moduleName>.client。

● RPC相關代碼: 包含RPC相關的代碼，可以轉換成JavaScript。該項目遵從與上述客戶端代碼項目同樣的指導準則。項目名是< ModuleName>-rpc，譬如“JUnit2MR-rpc”，它并不依賴于其他任何項目。程序包名稱與< ModuleName>-client項目的程序包名稱一樣。RPC項目包含客戶端上的遠程接口、RPC期間由GWT進行序列化的數(shù)據(jù)傳輸對象，以 及全局常量類。

● 服務器端代碼: 含有服務器小程序代碼，如果服務器端由Java服務器小程序組成的話。如果使用Tomcat 5.5或者Tomcat 6，可以充分利用Java 5+的全部功能。啟用每個項目的Eclipse編譯器設置，然后使用Java 5編譯器設置，依從級別設置為5.0。如果使用Eclipse 3.2.2，那么其新的“源代碼→清理”特性也值得配置。該項目名稱是< ModuleName>-server，譬如“JUnit2MR-server”，它依賴于構建路徑設置中的< ModuleName>-rpc項目。如果按照GWT的默認程序包提案進行編程，程序包名稱是< com.company.project>.gwt.< moduleName>.server。

忠告之二: 調試和錯誤報告不僅僅只有Window.alert ()

在創(chuàng)建GWT應用時，其實可以使用IDE的全部調試功能。但在深入分析何處可能出現(xiàn)錯誤之前，需要代碼的客戶端和 服務器端都有可靠的異常報告機制。使用try/catch代碼塊通常可以做到這一點。在客戶端的catch代碼塊中，應當注意這一現(xiàn)實: 默認的方法調用e.printStackTrace()并不是在所有情況下都適合的解決辦法。它適用于應用運行在GWT宿主模式下，把文本輸出到 Eclipse控制臺。不過在Web模式下，要問問自己: “我發(fā)送到stdout或者stderr的堆棧跟蹤信息和錯誤信息會在什么地方顯示？”一種可能的解決方法就是使用Mat Gessel的調試實用程序類（http://www.asquare.net/gwttk），但是需要瀏覽器JavaScript控制臺來查看Web模 式下的結果。

在客戶端，建議要做的一件事就是，使用GWT.setUncaughtExceptionHandler()方 法，為任何未被發(fā)現(xiàn)的異常提供自己的異常處理程序。發(fā)現(xiàn)了這幾種異常后，有幾個選擇: GWT.log（message, caught）、Debug.println (message_with_stacktrace); 如果使用Mat Gessel的Debug類，可選擇Window.alert（message_with_stacktrace），或者自己定制的錯誤報告。

視來源而定，會得到“無法裝入模塊”或者“未被發(fā)現(xiàn)的異常被漏過”的信息。筆者編寫了一個小小的DebugUtility類，它提供了易于定制的默認客戶端錯誤處理機制（見代碼片段1）。

在服務器端，可以使用java.util.logging API或者log4j的廣泛功能，具體取決于個人偏好或者項目的約束條件。但要是沒有為GWT的 com.google.gwt.user.server.rpc.RemoteServiceServlet類打補丁，對于未被發(fā)現(xiàn)、未被檢查的異常，只 會在堆棧跟蹤里面得到提示，指向生成該錯誤的服務器端類。對于catch()代碼塊里面發(fā)現(xiàn)及報告的被檢查的異常，一切都正常。

忠告之三: 當心GWT Shell的“刷新”按鈕陷阱

在宿主模式下啟動應用時，會在瀏覽器任務欄上看到“刷新”按鈕。要是摁了這個按鈕，GWT就會把修改過的Java 客戶端源代碼重新編譯成Java字節(jié)碼（作為.gwt.-cache/bytecode目錄中的.tmp文件），然后重新裝入模塊。可以使用這個按鈕來縮 短編輯→編譯→調試周期，但在使用這項特性時要牢記幾個方面:

● 只有修改過的源代碼才重新編譯，也就是說，不會為依賴修改過代碼的文件生成新的字節(jié)碼。所以，如果改變了全局常量的值，假設public final int字段的值，不會立即在相關文件看到這個變化。

● 只有修改過的源代碼才由GWT重新編譯。這意味著，即便Eclipse IDE里面的“Project clean”也幫不上忙; 要影響到所有的相關源代碼，譬如通過添加新的空行。

因為這個過程相當笨拙，筆者的忠告是在修改全局常量時遵循以下四個步驟:

1．在相應的源文件里面改變public final constant值;

2．重新編譯改變后的源代碼;

3．移除整個< ModuleName>-client/.get-cache/bytecode目錄，從而刪除GWT緩存內(nèi)容;

4、使用Eclipse里面的“Run as”，重新開始啟動應用，從而創(chuàng)建帶重新編譯后字符碼的新GWT緩存內(nèi)容，這種情況下，最好忽視“刷新”按鈕，不過在有些情況下，刪除整個< ModuleName>-client/.get-cache/bytecode目錄后可以使用“刷新”按鈕。

在修改服務器端代碼時，GWT字節(jié)碼緩存內(nèi)容不受影響。不過，嵌入的Tomcat實例會緩存它，因而在使用“刷新”按鈕后，只有重新開始啟動應用后最初改變的代碼才會得到認可。所以為了安全起見，改變服務器端代碼后，最好還是重新開始啟動應用。

忠告之四: 在宿主模式下讀取Servlet Init參數(shù)

在處理數(shù)據(jù)庫系統(tǒng)時，一般不希望服務器小程序源代碼中有硬編碼的數(shù)據(jù)庫連接參數(shù)。通常會從屬性文件讀取這些參數(shù); 或者更好的是，把它們作為init參數(shù)提供給服務器小程序（作為應用的Web.xml文件的一部分）。如果在Web模式下運行應用那沒有什么，但在宿主模 式下會出問題，這是由于GWT宿主模式下的服務器小程序處理存在限制。

好消息是，只要修改由嵌入式Tomcat實例使用的Web.xml文件，就可以解決這個問題。為此，修 改< ModuleName>-client/tomcat/webapps/ROOT/WEB-INF目錄中的Web.xml文件（或者必要時創(chuàng)建一 個）: 除了嵌入式Tomcat的GWTShellServlet映射外，添加帶有init參數(shù)的上下文部分。因為上下文信息是“全局性的”，而不是針對特定的服 務器小程序，在這里只有一部分的init參數(shù)信息，或者使用特殊的命名方案，把參數(shù)與不同的服務器小程序聯(lián)系起來。如果使用這個新的web.xml文件， 可以刪除src/web/WEB-INF文件夾中的那個舊文件。

在服務器小程序代碼中，訪問init參數(shù)的方式與Web模式下讀取它們的方式一樣，譬如final String host = getInitParameter("host")。筆者實現(xiàn)這一點的辦法就是修改GWT的RemoteServiceServlet，方法跟第二個忠告 里面的如出一轍。現(xiàn)在，只要覆蓋GenericServlet的getInitParameter()方法，以便使用 getServletContext()，而不是 getServletConfig()。

另一個忠告是，如果在宿主模式下和Web模式下測試不同的服務器代碼，略過Gant腳本中的GWT編譯部分，從“temp”位置拷貝編譯前的JavaScript代碼，則可以節(jié)省時間。這適用于客戶端代碼復雜、編譯時間超過10分鐘的情形。

忠告之五: 在瀏覽器里面顯示PDF文件

大多數(shù)實際的Web應用提供了生成及閱讀PDF文件的方法。本文假設這個PDF文件由服務器小程序生成，譬如通過 JasperReport。以后只要點擊某個超文本鏈接，就可以在瀏覽器里面閱讀生成的文件。如果想在宿主模式下和Web模式下測試這項特性，建議采取以 下步驟:

1．設計一個RPC接口，接受告訴服務器是在宿主模式下運行還是在Web模式下運行的布爾參數(shù)。接口方法會返回的字符串應當帶有服務器小程序生成的PDF文件的名稱（即文件名的最后一部分）。

2．根據(jù)代碼片段4顯示的代碼，實現(xiàn)服務器小程序代碼，這取決于布爾參數(shù)“isScript”。

3．在客戶端: 在窗口組件代碼里面，使用GWT.isScript()參數(shù)調用createXyzPDF()方法，從而生成包含服務器小程序結果字符串的外部超文本鏈接。

代碼片段4顯示了接口方法名為createSummaryPDF()的示例。從服務器小程序返回的字符串是“summary.pdf”。

這當然不是處理這種情況的惟一辦法，但目前適用于我們這個示例。請注意: 在宿主模式下啟動應用之前，必須在< ModuleName>-client project's src/…/public文件夾中至少創(chuàng)建一個虛假的“summary.pdf”文件（文件名從服務器小程序返回）。不然，在瀏覽器中點擊了超文本鏈接 后，GWT試圖讀取PDF文件時，會出現(xiàn)“HTTP 404－找不到網(wǎng)頁”的信息。

忠告之六:力求獲得無狀態(tài)服務器

設計客戶機/服務器Web應用時要考慮的一個關鍵問題就是: 如何處理會話和狀態(tài)管理？在Web 1.0時代，答案很顯然: 會話和狀態(tài)管理是一個服務器問題。但若使用GWT，就有另一個選擇。服務器再也不是只提供HTML內(nèi)容的“web”服務。使用GWT RPC，服務器現(xiàn)在可以支持只提供結構化數(shù)據(jù)的服務———在本文示例中，服務由服務器小程序實現(xiàn)。

那么，GWT對會話和狀態(tài)管理有何影響呢？GWT的技術領導Bruce Johnson在去年的JAOO大會上指出，若使用GWT，會話管理現(xiàn)在應當是一個客戶端問題。附圖顯示的幻燈片評述了種種變化。

在本文的JUnit2MR GWT應用中，筆者一開始使用傳統(tǒng)方法來處理服務器小程序中的會話狀態(tài)。但這是相當笨拙的任務，于是尋找另一種選擇。因此，看了Bruce的幻燈片后，決 定重新設計整個應用。但這一步需要改變所有RPC接口、緩存策略; 最重要的是，還要改變所有的服務器小程序。因此筆者的建議是: 及早考慮在何處實施會話和狀態(tài)管理，不妨試試Bruce Johnson的訣竅。最終會收到成效。

由于這個決定，客戶端對象之間有了更多的聯(lián)系。于是筆者使用了有名的GoF中介者模式（mediator pattern）。不過，在客戶端有一些JDK 1.4和GWT運行庫的限制。因此，重新實現(xiàn)了PropertyChangeEvent類和中介者支持，來處理監(jiān)聽程序注冊和消息廣播。

忠告之七: 使用Selenium實現(xiàn)GWT Web測試的自動化

Selenium是一種開源工具，它能夠輕松測試包含豐富、互動的客戶端內(nèi)容的Web應用。 所以，它非常適用于測試像用GWT創(chuàng)建的應用那樣的Ajax應用。

當然，GWT里面仍有JUnit和JUnit支持功能，特別是針對系統(tǒng)的異步部分。這里著重介紹 Selenium，因為它易于使用（至少它的IDE是這樣）、功能強大。最后但并非最不重要的一點是，它與JUnit有許多共同之處。可以使用 Selenium IDE來記錄GUI用例，然后使用其“Play”特性來運行記錄下來的操作。每個操作之后跟著類似JUnit的“assert”命令，負責確認頁面上的某 些文本。該IDE是Firefox的擴展插件，但務必要使用最新版本的Selenium: Selenium IDE 0 .8 .7，因為它包含了“waitFor…”命令的重大修正版。說到測試Ajax應用，這些命令以及“pause”命令非常重要。

忠告之八: 使用Groovy Gant腳本部署應用

在GWT宿主模式下試運行應用，這確實很好，但把應用部署到應用服務器上或者類似Tomcat的服務器小程序容器 上，GWT的真實功能才會體現(xiàn)出來。在這一步，需要創(chuàng)建一個war文件，它會自動拷貝到Tomcat“webapps”目錄。當然，可以使用Ant和 ant-contrib進行所有必要的準備、編譯、拷貝及其他任務。但由于Ant腳本變得更復雜后， ant-contrib控制結構和屬性regex處理有一點笨拙。于是可以使用集Groovy和Ant兩者之所長的Gant。安裝Groovy和Gant 用不了10分鐘，然后，使用來自“build.properties”文件的普通屬性，即可定制“build.gant”腳本。（小黑編譯）

（計算機世界報 2007年6月25日 第24期 B22、B23）