使用IBM Rational Application Developer輕松實現JavaServer Faces Web程序的

使用IBM Rational Application Developer輕松實現JavaServer Faces Web程序的全球化

在 RAD V7 或者後續版本中使用 JavaServer Widgets Library（JWL）

了解如何使用 IBM Rational Application Developer 來實現 JavaServer Faces Web 程序的全球化。本文描述了開發全球市場所面臨的挑戰，並介紹了怎樣使用 JavaServer Faces Widget Library（JWL）來處理這個問題。

從版本 7 開始，IBM®Rational®Application Developer 包含了 JavaServer Faces Widget Library（JWL），它是一個 Java™Server Faces （JSF）- 以及用於快速開發網絡程序的基於 JavaScript 的庫。

JWL,hxclient 的 JavaScript 庫，實施了對 JWL 構件的客戶端支持。它還包含了一系列所謂的“JSF 轉化器”，可以幫助開發員分析和格式化日期，時間以及特定位置模式的來回號碼，更特別的是，這些工具就是 JavaSimpleDateFormat 和 DecimalFormat 的 JavaScript 實施。這些工具對於設計成支持多種語言的程序來說十分有用，因為它們幫助您處理來自客戶端位置敏感數據輸入和輸出的挑戰。

本篇文章還解釋了與 JavaServer Faces 程序中多線程相關的全球化挑戰問題，並提供了一個解決方案。本文作者假設您有關於 JSF 和 JWL 的基礎知識。

全球化基礎知識

在網絡程序中，輸出語言是由 HTTP 請求報頭的 Accept-Language 區域所決定。用戶可以指定喜好的語言和帶有浏覽器設置的場所。

JSF 框架分析 HTTP 請求報頭。您可以通過使用如列表 1 所示的報頭來獲取該值。

列表 1. 獲取關於語言和場所的請求

Locale　locale　=　FacesContext.getCurrentInstance().getExternalContext().getRequestLocale();

場所值用於決定用於顯示的預言。

使用 JWL 來處理場所敏感輸出與輸入

在快速引入全球化之後，現在我們已經做好准備，討論全球化 JSF 網絡程序中面臨的兩個挑戰：

使用本地格式顯示客戶日期和時間

顯示和結束本地數字格式

hxclient 在頁面中是怎樣初始化的

只要您在使用頁面中的 JWL 標簽，您就必須確保頁面中安裝有庫，並得到了合適的初始化。如果您設置了浏覽器場所請求為“ja”（日語），並查看使用 JWL 調用的 HTML 頁面的源代碼，您將會發現如列表 2 所示的代碼。

列表 2. 使用 JWL 的網絡頁面的結構

<script　type="text/JavaScript"　language="JavaScript"
src="/sample/.ibmjsfres/hxclient_core_v3_0_8.js"></script>

<script　type="text/JavaScript"　language="JavaScript"
src="/sample/.ibmjsfres/hxclient_S_v3_0_8_ja.js?viewLocale=ja">
</script>

<script　type="text/JavaScript"　language="JavaScript">
　　 if　(hX_5)　hX_5.setResourceServer("/sample/.ibmjsfres");
　　 if(hX_5　&&　hX_5.setLocale)　hX_5.setLocale("ja");
</script>

該代碼可以完成三件事：

包含頁面上的 hxclient 內核腳本庫

包含頁面上的 hxclient 場所特定的腳本庫

創建當前的頁面場所

正如您所看到的那樣，您不需要手動創建場所，因為 JWL 會通過閱讀場所請求來自動決定場所。對於 hxclient 的自動初始化，您已經做好准備將其用於日期，時間和數字格式了。

使用 JWL 的本地格式來顯示客戶日期和時間

對於網絡程序，開發員想要顯示頁面上的最新請求時間。在全球化的程序中，時間必須是當地格式的。

例如，一個美國的用戶可能會想要按以下方式查看日期時間格式 ：

Last Refresh: Friday, May 8, 2009 1:35:07 PM GMT+08:00

但是一個日本的用戶也許會看到如下所示的日期時間格式：

前回の最新表示: 2009 年 5 月 8 日金曜日 13 時 41 分 07 秒 GMT+08:00

因為時間是在客戶端計算的，所以 JavaScript 並沒有通過內置 API 來提供一個方案：Date.toLocaleString(). 這是因為：

返回值的場所並不是由浏覽器的場所設置所決定的，而是由客戶操作系統的場所決定。

開發員沒有機會指定日期的格式。

日期時間轉換器是 JWL 客戶腳本庫的一個工具。它是 Java SimpleDateFormat 類的 JavaScript 實施，它可以很好的支持 ICU4J（Unicode Java 庫的國際構件 Library）。它使得客戶端的日期/時間格式變得像處理 Java™一樣容易。在本例中，我們使用 DateTimeConverter 和 ICU4J 來生成客戶端的本地日期/時間。

為了快點開始，讓我們來看客戶端的腳步是什麼樣的：

列表 3. JavaScript 的日期/時間格式

function　getLocalizedCurrentTime()　
{　
　　var　converter　=　hX.getConverterById("date_converter");
　　if(null　==　converter)　
　　{　
　　　　//construct　a　new　DateTimeConverter　and　add　it　to　converter　set　
　　　　hX.addConverter("date_converter",　new　hX.DateTimeConverter(　
　　　　　　"format:EEEE,　MMMM　d,　yyyy　h:mm:ss　a　z",　
　　　　　　"ICU4J:true"));
　　}
　　converter　=　hX.getConverterById("date_converter");
　　var　date　=　new　Date();
　　//format　client　date　and　return
　　return　converter.valueToString(date);
}　

您所要做的只是定位日期/時間。但是這些參數會傳遞給 DateTimeConverter 構建器：

“ICU4J:true” 允許 DateTimeConverter 接受模式的特定 ICU 特征。

“format:EEEE, MMMM d, yyyy h:mm:ss a z” 意味著 DateTimeConverter 用於格式化日期/時間的模式。

到目前為止，我們已經向您展示了，您需要什麼客戶代碼來格式化日期/時間。但這並不足夠。考慮一下模式。您知道對於不同的場所模式會是什麼樣的嗎？

例如，對於美國用戶的模式是這樣的：

EEEE，MMMM d，yyyy h:mm:ss a z

而日本客戶的模式是這樣的：

yyyy'年'M'月'd'日'EEEE H'時'mm'分'ss'秒'z

還好模式並不是硬代碼的，因為開發員並不可能知道不同場所的所有模式。像 “yyyy mm dd”這樣的模式對於某個開發員來說可能是合理的，但是對用戶看來就是很古怪的 。

因此，答案就是從服務器端獲取模式，因為 ICU4J 已經為所有開發員的使用准備好了模式。列表 4 中的代碼展示了，我們怎樣根據本地的請求獲取一個模式：

列表 4. 通過使用 ICU4J 來生成日期/時間模式

public　class　FormatterUtils
{
　　 public　static　String　getDateTimePattern(int　dateFormat)
　　 {
　　　　 Locale　locale　=
　　　　　　 FacesContext.getCurrentInstance().getExternalContext().getRequestLocale();
　　　　 CalendarData　calData　=　new　
　　　　　　 CalendarData(ULocale.forLocale(locale),　null);
　　　　 String[]　dateTimePatterns　=　calData.getStringArray("DateTimePatterns");
　　　　 return　dateTimePatterns[dateFormat　+　4]　+　"　"　+　dateTimePatterns[dateFormat];
　　 }
}

參數 dateFormat 顯示了格式模式使用的方法。基本上，在 ICU com.ibm.icu.text.DateFormat 類中有四種預定義的類型：

Full

Long

Medium

Short

對於不同格式的參數，方法 getDateTimePattern 的返回值也有所不同。例如，對於 en-us 場所，有四種類型的返回值：

EEEE，MMMM d，yyyy h:mm:ss a z

MMMM d，yyyy h:mm:ss a z

MMM d，yyyy h:mm:ss a

M/d/yy h:mm a

所以通過從四個類型中選擇一個，您已經准備好了格式模式，讓我們假設您使用的是 Full 格式。下一步是將該格式模式應用到客戶端，以使用 hxclient。在 Java™Server Pages（JSP™）腳本中，這很容易做到。對於客戶端的模式，JavaScript 代碼應該像列表 5 所示。

列表 5. 將格式模式捆綁到客戶代碼

<script>
　　var　datetimeFormatPattern　=　"<%=FormatterUtils.getDateTimePattern()%>";
　
　　function　getLocalizedCurrentTime()　
　　{　
　　　　var　converter　=　hX.getConverterById("date_converter");
　　　　if(null　==　converter)　
　　　　{　
　　　　　　//construct　a　new　DateTimeConverter　and　add　it　to　converter　set　
　　　　　　hX.addConverter("date_converter",　new　hX.DateTimeConverter(　
　　　　　　　　"format:"　+　datetimeFormatPattern,　"ICU4J:true"));
　　　　}
　　　　converter　=　hX.getConverterById("date_converter");
　　　　var　date　=　new　Date();
　　　　//format　client　date　and　return
　　　　return　converter.valueToString(date);
　　}
</script>

現在已經完成了。通過調用 JavaScriptgetLocalizedCurrentTime 方法，您可以得到客戶端的日期和時間文本（例如，圖 1 顯示是英語，圖 2 顯示的是日語）。

圖 1. 顯示 en-us 的日期和時間

圖 2. 顯示 ja-jp 的日期和時間

顯示和接受本地 JWL 的數字格式

顯示帶有本地格式的數字，與顯示日期/時間相類似。像 1000.1 這樣的十進制數字在美國應該顯示成 1,000.1，而在德國會顯示成 1.000,1。

不像日期和時間，這些數字應該從服務器端獲得，在這裡 ICUDecimalFormat 可以完成這一點。但是有些情況下，您可能想要格式化客戶端的數字（例如，接受用戶輸入並顯示值）。在 JWLhxclient 庫中， NumberConverter 實施了客戶端上 DecimalFormat 的邏輯。

同樣，讓我們首先直接跳到完整的客戶代碼：

列表 6. 格式數字的 JavaScript

<script>
　　 var　decimalFormatPattern　=　"<%=　FormatterUtils.getDecimalFormatPattern()　%>";
　　 var　decimalFormatSymbols　=　"<%=　FormatterUtils.getDecimalFormatSymbols()　%>";

　　 function　formatDecimal(value)
　　 {
　　　　 var　converter　=　hX.getConverterById("number_converter");
　　　　 if(null　==　converter)
　　　　 {
　　　　　　 hX.addConverter("number_converter",
　　　　　　　　 new　hX.NumberConverter("pattern:"　+　decimalFormatPattern,
　　　　　　　　 "locale:"　+　decimalFormatSymbols,　"ICU4J:true"));
　　　　 }
　　　　 converter　=　hX.getConverterById("number_converter");
　　　　 var　output　=　cvt.valueToString(value);
　　　　 return　output;
　　 }
</script>

有三種參數會傳遞給 NumberConverter 構建器：

“ICU4J:true”：它允許 NumberConverter 接受在模式中 ICU 特定的特征。

“pattern：”+ decimalFormatPattern： 這是在轉化值的時候會用到的數字模式。

“locale：” + decimalFormatSymbols： 這是轉化值時會用到的場所信息。它包含了十進制分隔符，百分比字符等等之類的符號。

至於 DateTimeConverter，模式和場所信息應該從服務器端獲得：

列表 7. 使用 ICU4J 來生成數字模式和符號

public　class　FormatterUtils
{
　　 private　static　DecimalFormat　getDecimalFormatter()
　　 {
　　　　 Locale　locale　=
　　　　　　 FacesContext.getCurrentInstance().getExternalContext().getRequestLocale();
　　　　 return　(DecimalFormat)NumberFormat.getInstance(locale);
　　 }

　　 public　static　String　getDecimalFormatPattern()
　　 {
　　　　 return　getDecimalFormatter().toPattern();
　　 }

　　 public　static　String　getDecimalFormatSymbols()
　　 {
　　　　 Locale　locale　=
　　　　　　 FacesContext.getCurrentInstance().getExternalContext().getRequestLocale();
　　　　 DecimalFormatSymbols　symbols　=　new　DecimalFormatSymbols(locale);
　　　　 //The　information　is　provided　as　a　string　of　6　characters　with　fixed　format:
　　　　 StringBuilder　sb　=　new　StringBuilder();
　　　　 sb.append(symbols.getGroupingSeparator());
　　　　 sb.append(symbols.getDecimalSeparator());
　　　　 sb.append(symbols.getPercent());
　　　　 sb.append(symbols.getPerMill());
　　　　 sb.append(symbols.getMinusSign());
　　　　 sb.append(symbols.getCurrencySymbol());
　　　　 return　sb.toString();
　　 }
}

正如您在列表 6 中看到的那樣，getDecimalFormatPattern 和 getDecimalFormatSymbols 用於傳遞頁面中的模式和場所信息。對於服務器端的協助，您可以使用 JavaScriptformatDecimal() 功能，來格式化 JavaScriptNumber 類型變量。列表 8 向您展示了一個這樣的例子。

列表 8. 使用客戶代碼來格式化數字

<script>
　　 //Suppose　current　locale　is　"de"
　　 var　value　=　1000.1;　//type　of　value　is　Number
　　 var　formatted　=　formatDecimal(value);　//the　formatted　value　is　"1.000,1"　in　Germany
</script>

頁面中的數字通常會像圖 3 那樣格式化（該例展示了德語中的匯容量統計）：

圖 3. 頁面中的格式化數據：

在處理數字時，不但要注意輸出還要注意輸入。輸入隨著用戶的習慣而不同。一個德國的用戶可能會輸入 1.000,1 或者 1000,1。但是這兩種格式的數據都應該識別為十進制的數據 1000.1。對於開發員來說，這是一個艱難的任務，因為他們需要寫上千行的代碼以識別輸入。

好的消息是 JWLhxclient 可以轉換數字。您可以使用該功能來將用戶輸入轉化為 JavaScript Number 對象。該對象通過自動執行這些步驟，來將顯示的數字和值區別開來：

接受用戶輸入。

通過使用 NumberConverter，來分析 String 對象的輸入到 Number 對象。

使用轉化值以進行計算。

通過再次使用 NumberConverter，來將計算結果格式化回至 String 對象。

使用格式化的值以進行顯示。

列表 9 中的代碼舉了一個例子，展示了怎樣分析用戶輸入（對於 Deutsch 或者 German，場所是“de”）：

列表 9. JavaScript 分析的輸入數字

<script>
　　 var　decimalFormatPattern　=　"<%=　FormatterUtils.getDecimalFormatPattern()　%>";
　　 var　decimalFormatSymbols　=　"<%=　FormatterUtils.getDecimalFormatSymbols()　%>";

　　 function　formatDecimal(input)
　　 {
　　　　 var　converter　=　hX.getConverterById("number_converter");
　　　　 if(null　==　converter)
　　　　 {
　　　　　　 hX.addConverter("number_converter",
　　　　　　　　 new　hX.NumberConverter("pattern:"　+　decimalFormatPattern,
　　　　　　　　 "locale:"　+　decimalFormatSymbols,　"ICU4J:true"));
　　　　 }
　　　　 converter　=　hX.getConverterById("number_converter");
　　　　 var　output　=　cvt.stringToValue(input);
　　　　 return　output;
　　 }

　　 var　parsedValue　=　formatDecimal("1.000,1");　//the　parsed　value　is　1000.1
　　 parsedValue　=　formatDecimal("1000,1");　//the　parsed　value　is　1000.1
　　 parsedValue　=　formatDecimal("oops");　//parsing　fails,　null　is　returned
</script>

列表 9 中的代碼在以下方面與列表 6 十分相似：從服務器端獲取模式和場所信息，創建一個 NumberConverter 的范例，然後執行該任務。唯一的區別是調用的方法：stringToValue(). 方法的名字是不言而喻的：它分析一個 String 對象，並試著將其轉化為 Number 對象。如果在轉化期間發生了什麼錯誤，那麼該方法將會返回 null。因此，NumberConverter 也可以用於識別用戶輸入。

到目前為止，我們已經介紹了 JWLhxclient 腳本是怎樣幫助您處理客戶端的數字分析和格式問題。在例子中的代碼中，我們總是需要得到服務器端的場所信息，以生成格式模式。因此，在接下來的章節中，我們將會討論更高級的話題，就是場所信息是怎樣傳遞的，以及在 JSF 網絡程序中是怎樣使用這些信息的。

在多線程 JSF 程序中全球化道路的風險

使用 JSF 進行全球化很容易，但是並不是極簡單的。特別是在多線程的程序中，如果設計缺乏完善的考慮，錯誤的假設將會使得您的全球化支持，變得更像是應用一系列的補丁。接下來我們將要介紹的技術，將會使得您的多線程 JSF 程序變得更加強壯。

決定顯示的語言

全球化通常構建於場所的基礎之上。因此，怎樣實現全球化歸根結底就是怎樣處理場所。在獲取場所信息之後，您已經可以決定基於場所用戶界面中顯示的語言。在大多數情況下，JSF 框架會關注帶有 <loadBundle> 標簽的語言包，它根據場所請求獲取包，而不需要額外的編碼。但是如果您需要使用 Java 代碼中的語言包內容，那麼您就需要使用場所信息來獲取包的路徑，然後自己格式化信息。列表 10 給出了范例代碼。

列表 10. 一個簡單的信息格式化范例

public　class　MessageFormatter　{
private　static　final　String　MESSAGE_BUNDLE_NAME　=　"com.ibm.sample.messages";

private　static　String　formatMessage(String　msgKey,　Object[]　args,Locale　locale)　{
　　 ResourceBundle　messageBundle　=　ResourceBundle.getBundle(MESSAGE_BUNDLE_NAME,locale);
　　 String　message　=　messageBundle.getString(msgKey);
　　 if　(message　!=　null)　{
　　　　 if　(args　==　null)　{
　　　　　　 return　message;
　　　　 }　else　{
　　　　　　 return　MessageFormat.format(message,　args);
　　　　 }
　　 }　else　{
　　　　 return　msgKey;
　　 }
}
}

得到請求的場所

我們可以看到文本文件中列表 10 所示的代碼，它解釋了怎樣使用 Java 方法來實現全球化。但是在實際操作時當您看到大量 getRequestLocale 存在時是很痛苦的，如列表 1 所示，叫做格式化信息之前。

提示：

查看 IBM Java 技術庫以得到關於 輕松使用線程：不共享有時是最好的變量的更多信息。

接下來，我們將會向您展示怎樣讓工作變得更加完美。

您已經知道，JSFFacesContext 是作為服務線程中的一個 ThreadLocal 變量保存的。因為所有的 Faces backend 豆是在服務線程中運行的，所以您可以在任意時刻獲取 FacesContext 對象。對於場所對象 T 也是真實的，因為它是從 FacesContext 獲取的。這樣您就可以將場所獲取方法放在工具類中，來重寫列表 10 中的代碼，如列表 11 所示。

列表 11. 獲取信息格式化器的最佳方法

public　class　LocaleUtils(){
public　class　LocaleUtils{}　{
public　static　Locale　getRequestLocale()　{
　　 return　FacesContext.getCurrentInstance().getExternalContext().getRequestLocale();
}

}
public　class　MessageFormatter　{
private　static　final　String　MESSAGE_BUNDLE_NAME　=　"com.ibm.sample.messages";

private　static　String　formatMessage(String　msgKey,　Object[]　args)　{
　　 Locale　locale　=　LocaleUtils.getRequestLocale();
　　 ResourceBundle　messageBundle　=　ResourceBundle.getBundle(MESSAGE_BUNDLE_NAME,　locale);
　　 String　message　=　messageBundle.getString(msgKey);
　　 if　(message　!=　null)　{
　　　　 if　(args　==　null)　{
　　　　　　 return　message;
　　　　 }　else　{
　　　　　　 return　MessageFormat.format(message,　args);
　　　　 }
　　 }　else　{
　　　　 return　msgKey;
　　 }
}
}

然後 MessageFormatter.formatMessage 就成為從語言包中獲取信息的唯一方法了，它會返回基於請求的信息。現在您可以忽略場所了，因為在 LocaleUtils 的支持下它現在透明地為您工作了。

將請求場所傳遞給用戶線程

如果您想讓場所自動地工作，那麼現在您做的還不夠。

當您在處理多線程程序時，還有一個例外。在多線程程序中，用戶定義的線程並不是由服務線程初始化的，因此它們並沒有將 FacesContext 初始化為一個 ThreadLocal 變量。結果，在該線程中運行的代碼在格式化信息時，就不能訪問場所信息了。

對於以上問題通用的解決方法，是通過在構造變量期間將其傳遞給用戶線程，來讓每一個用戶都有一個場所變量。當變量在線程中准備好時，您可以使用列表 10 中所示的范例代碼，來在用戶線程中運行代碼以實現全球化。但是，這需要編輯用戶線程構造器及其調用的代碼。有一種方法可以讓它更加完美地工作。

我們知道至少有一個用戶線程（或者是它的上級線程）會在服務線程中實現。換句話說，至少有一個用戶線程的構造器在服務線程中得到訪問。因為用戶線程構造器中的代碼仍然在訪問線程的環境下運行，所以在構造用戶線程時，我們還有機會從服務線程繼承場所對象。這樣我們將可以傳遞實現每一個子線程初始化的場所對象。這樣我們就有了 LocaleUtils 的升級版本，這樣通過實施 LocaleSensitive 界面，在用戶線程成為場所敏感的線程之後，在多線程環境中它就可以更好地工作了，就像我們在 BaseThread 中所做的那樣（見於列表 12）。

列表 12. 場所敏感的基底線程

public　static　Locale　DEFAULT_LOCALE　=　Locale.ENGLISH;

　　 public　static　Locale　getCurrentRequestLocale()　{
　　　　 Locale　locale　=　null;
　　　　 try　{
　　　　　　 //try　to　retrieve　locale　information　from　FacesContext
　　　　　　 locale　=　FacesContext.getCurrentInstance().　
　　　　　　　　 getExternalContext().getRequestLocale();
　　　　 }
　　　　 catch(Throwable　e){
　　　　　　 //Unable　to　reach　FacesContext
　　　　　　 //Therefore　call　getLocale　to　retrieve　locale　variable　from　current　thread
　　　　　　 Thread　t　=　Thread.currentThread();
　　　　　　 if　(t　instanceof　LocaleSensitive)　{
　　　　　　　　 locale　=　((LocaleSensitive)　t).getLocale();
　　　　 }
　　　　 finally{
　　　　　　 if(locale　==　null){
　　　　　　　　 locale　=　DEFAULT_LOCALE;
　　　　　　 }
　　　　 }
　　　　 return　locale;
　　 }
}

public　interface　LocaleSensitive　{
　　 public　Locale　getLocale();
}

public　class　BaseThread　extends　Thread　implements　LocaleSensitive　{
　　 protected　Locale　locale=　null;

　　 public　Locale　getLocale()　{
　　　　 return　locale;
　　 }

　　 public　BaseThread(String　name)　{
　　　　 super(name);
　　　　 //Save　a　copy　of　locale　in　thread　instance
　　　　 this.locale=LocaleUtils.getCurrentRequestLocale();
　　 }
}

public　class　UserThread　extends　BaseThread{
　　 public　void　run(){
　　　　 …　
　　　　 String　message　=　MessageFormatter.formatMessage(msgKey,msgParameters);
　　　　 …　
　　 }
}

首先，您需要定義一個名為 LocaleSensitive 的界面。任何一個實施該節目的類都應該提供 getLocale() 方法中的場所信息。

然後您使用 BaseThread 來實施 LocaleSensitive 線程。BaseThread 構造器通過訪問 LocaleUtils.getCurrentRequestLocale() 來得到場所對象，它從 FacesContext 中（在服務環境下），或者上級線程中得到場所信息（這就解釋了場所信息是怎樣傳遞的）。然後如果有用戶線程成為 BaseThread 的子類，該線程可以使用 MessageFormatter，而不需升級版本的 LocaleUtils 類，就像我們在服務環境下所做的那樣。

使用列表 12 中的代碼，您就可以在任何線程中傳遞和得到場所信息了，而無需擔心 FacesContext 是否可以訪問。現在多線程 JSF 網絡程序中的風險就不復存在了。

總結

IBM Rational Application Developer 中的 JavaServer Widgets 庫，提供了腳本幫助開發員處理客戶端的全球化問題，這使得全球化開發變得更加容易。在您處理多線程的網絡程序時，要十分謹慎，因為您需要掌握一定的技巧，以確保在程序的任何地方都能夠訪問場所信息。