從外部應用程式傳送引數到基於 JSR 286 的 Web Content Viewer portlet

簡介： 新版基於 JSR 286 的 Web Content Viewer portlet 是 IBM® WebSphere® Portal V6.1.5 的一部分，其中增加了大量新功能，而且有許多優勢。如果您想從一個外部應用程式傳送引數到 portlet，新版和舊版的差異非常大。本文向您介紹如何輕鬆地傳送引數到新 portlet，以及存在差異的原因。 本文來自於 IBM WebSphere Developer Technical Journal。

新舊對抗

新 Web Content Viewer portlet 的第一版於 2009 年 1 月在 IBM® Lotus® and WebSphere® Portal Business Solutions Catalog 中提供。升級版在 2009 年底釋出，其中包括 IBM WebSphere Portal V6.1.5 功能部件包。除了許多新功能之外，升級版也是以 Java Portlet Specification JSR 286 第 2 版為基礎的。儘管這包含了許多新功能，但較之早期的 Web Content Viewer（基於 IBM Portlet API 的）也有一個缺點：傳遞一個引數到檢視器 portlet 變得有點複雜。在這篇專欄文章中，您將會有意外的收益。

在 IBM Portlet API 版本的檢視器中，您只需要簡單地向正在尋找頁面的 URL 中新增一個查詢引數，該頁面上所有的 IBM portlet 將收到該引數，然後您配置 portlet 來監聽廣播並建立一個如下格式的 URL：

清單 1

				
http://[PORTAL_HOST]/[PORTAL_CONTEXT_ROOT]/[PORTAL_PAGE_URL_MAPPING]/?WCM_GLOBAL_CONTEXT=
/[LIBRARY]/[SITE]/[SITE_AREA_PATH]/[CONTENT]

例如：http://mysystent/wps/portal/home?WCM_GOBAL_CONTEXT=/mynewslib/usnews/news1。

這個 portlet 用起來很簡單，但是它也有以下缺點：

• 由於引數不能儲存在 URL 中，而要儲存在會話中（即使在非同步使用情況下），因而影響門戶伺服器記憶體消耗。
• 一旦與頁面互動，引數將不再在 URL 中 — 而儲存在會話中 — 您不再需要將您的選擇加入書籤。
• 快取在瀏覽器中的靜態頁面將不再有效，因為選擇內容不能被編碼成 URL。這意味著瀏覽器不能分辨新聞 1 和新聞 2 ，因此也不能在瀏覽器上快取。

讓我們看看在 JSR 286 新時代檢視器是如何工作的。

在新的檢視器中，您可以在 WebSphere Portal 中使用 URI 分解器框架來從外部系統尋找網頁或內容項。URI 分解器框架是一個普通的框架，也可用來促進定製 URI 模式。Web Content Management 定義模式 wcm: 如下：

wcm:path:LIBRARY/SITE_AREA_PATH/CONTENT [[& page=unique_name | object_id] &mapping=mapping | &current=true]

這意味著您可以提供路徑給內容，選擇提供下面之一：

• 一個目標頁面，使用惟一的頁名或其物件 ID 。
• 一個 URL 對映。
• 在 URL 中選定的、要在 URI 之前使用的當前頁面。

如果您不能提供上述任何一個，WebSphere Portal 自動嘗試尋找正確的頁面。只有當您正在使用 Web Content Pages 時該方法才有效，在這個 Web Content Pages 中您可以將 Web Content Management 網站區域（site area ）對映到門戶頁面，以便於 WebSphere Portal 意識到它們之間的關聯。

因此，現在您如何獲取一個完整的 URL 呢？有兩個不同的選擇：

• 直接通過 /wps/poc or /wps/mypoc 訪問 WebSphere Portal 分解器框架。
• 為 WebSphere Portal 使用外部應用程式瞭解的任何 URL。

我們來看一個 Web Content Management Web Content library 設定樣例，包含以下內容：

• 一個網站區域 NewsUS 和內容項 News1、News2、News3。
• 一個網站區域 NewsEurope 和內容項 News4、News5、News6。
  
  圖 1. Library Explorer
  
  
  
• 以下門戶頁面有友好的名稱：
  • 頂級：Products、Company News
  • 第二級：Products/Cars、Products/SUVs、Company News/US、Company News/Europe
  • 美國和歐洲是 Web Content pages。美國被對映到 Web Content Management 網站區域 Web Content/NewsUS，而歐洲被對映到 Web Content Management 網站區域 Web Content/NewsEurope。

圖 2 是歐洲頁面屬性的高階部分，其中顯示了到 NewsEurope Web Content Management 網站區域的對映。

圖 2. 歐洲頁面屬性的高階部分

我們也將定義一個 URL 將 /coolCars 對映到 Products/Cars 頁面，這樣 URL 將會連結到 http://host_name/wps/portal/Products/Cars。

以下是一些樣例 URL：

• 直接訪問門戶分解器框架：

  http://host_name/wps/mypoc?urile=wcm%3Apath%3A/Web+Content/NewsUS/News1

  這個 URL 通知門戶使用庫路徑 Web Content/NewsUS/News1 呈現內容項。WebSphere Portal 將查閱對映到 NewsUS 網站區域（Company News/US）的 Web Content Page，重定向到那個頁面，然後將該頁面的上下文設定為內容項庫路徑。

• http://host_name/wps/mypoc?urile=wcm%3Apath%3A/Web+Content/NewsUS/News1&mapping=/coolCars

  這個 URL 通知 WebSphere Portal 用和之前 URL 一樣的方式來呈現內容項，但是不進行動態頁面查閱來重定向到頁面 /Products/Cars，該頁面被對映到 URL /coolCars，如圖 3 所示。

  
  
  圖 3. 通過將 /coolCars 對映到選中的 Products/Cars 頁面訪問目標頁面
  
  
  
• 通過一個友好的 URL 訪問門戶：

  http://host_name/wps/portal/Company+News/Europe?urile=wcm%3Apath%3A/Web+Content/NewsUS/News2&current=true

  這個 URL 通知 WebSphere Portal 選擇頁面 /Company News/Europe 並顯示該頁面上的內容項 Web Content/NewsUS/News2。注意如果沒有引數 current=true，WebSphere Portal 將重定向到頁面 /Company News/US，因為這就是那個對映到 NewsUS 網站區域的頁面。

圖 4. 使用友好的 URL 路徑 Company News/Europe 訪問頁面並呈現 USNews 網站區域

在目標頁面上至少必須有一個 JSR 286 web 內容檢視器 portlet，而且必須被配置來接收來自其他 portlets 和自身 portlets 的連結，如圖 5 所示。

圖 5. 配置來接收來自其他 portlet 連結的 JSR 286 Web Content Viewer Portlet

portlet

為什麼這些用於訪問新檢視器埠的 URL 沒有上文指出的簡易架構那麼漂亮，而包含所有這些特殊字元呢？接下來我們將討論這個問題。

您可能知道有效的 URL 需要遵守 RFC 1738 定義的特定的編碼規則，必須替換保留字，例如 “ ”（空格）或 “：”。在上述例子中，“ ”（空格）被 “+” 替換，“：”被" %3A 替換。

還有一個細節我們沒有解釋，“urile” 來自之前的模式。實際上，您有兩個選擇：您可以指定 “uri” 或者是 “urile”。 不同之處是如果您使用 uri 模式，除了要遵守 URL 編碼規則之外，您還要遵守 URI 編碼規則，因此 URL 是：

http://host_name/wps/portal/Company+News/NewsEurope?urile=wcm%3Apath%3A/Web+Content/NewsUS/News2&current=true

像這樣使用 “uri” 模式：

http://host_name/wps/portal/Company+News/NewsEurope?uri=wcm%253Apath%253A%2FWeb%2BContent%2FNewsUS%2FNews2%26current%3Dtrue

關於如何編碼 URI 特殊字元的更多資訊，見 RFC 3986 。因為手工構造這些 URL 比較困難，WebSphere Portal 提供了一個簡化的 URI 版本，僅僅需要進行 URL 編碼而不是使用 urile 模式進行 URI 編碼。

Java Portlet Specification V 2.0 (JSR 286) 定義了所謂的呈現引數，這些引數被提供給每個請求的 portlet。例如，當使用者按下瀏覽器的重新載入按鈕時，portlet 再一次獲取相同的呈現引數，並能夠呈現相同的檢視。這意味著 portlet 不再需要在會話中儲存導航狀態資訊，基於 portlets 的 IBM Portlet API 就是最好的例子。

有兩個不同型別的呈現引數：私有引數，它們對頁面上的每個 portlet 視窗都是私有的；公共引數，它們是共享的。公共引數使您可以在舊的 IBM Portlet API 中向 URL 新增一個查詢引數，並可以用 portlets 在頁面上接收。舊 IBM Portlet API 查詢引數解決方案有兩個弊端：

• 您只能獲得一個請求的引數，之後頁面上的每個 portlet 需要在對話中儲存該值，這需要有會話，甚至在匿名使用的情況也需要有會話。
• 您不知道 portlet 能夠理解什麼樣的引數，因為 portlet 沒有正式宣告，甚至在兩個 portlet 定義相同的引數名的情況下您也可以執行，但是不同的語義可能會阻止您將兩個 portlet 放在同一頁面上，而且您事先是不知道的。

為了克服這些限制，JSR 286 規範定義了公共引數並使用了 QName 命名模式來命名引數，QName 命名模式在 XML 文件中很著名（見 Namespaces in XML 1.0）。WebSphere Portal 將引數名和引數值作為 URL 其中一部分儲存在頁面上，以至於那些 URL 是可設定標籤的（bookmark-able），並避免了使用一個會話。因為您可能有許多公共和私有呈現引數需要儲存在 URL 中，需要保證 URL 不太長。WebSphere Portal 通過壓縮編碼進行這些操作，看起來像這樣：

清單 2

				
http://sh1.svl.ibm.com:10046/wps/myportal/Home/Company-News/us/!
ut/p/b1/hc7LDoIwEIXhZ_EBzExppbIcSxSUi4AidGNIvAQiaiLB6NOLxo0LddbffzKgIRcmsyRyxiEDfSzacl805
elYHCAHreU6Sv3YkbGBkzGZ6LrWwHFtwRElZG25vT4zbX5nZgfyDqgJOUJ6iEOaPoGwpnMaMCT2r19BhmKdVMOzf2
sy767aRXWPsKkiI6jU7WJH1yZYzDdpvByRvULy6q7Rn7OhP1Pd7CzkPFQME-MNfr31AvjlCCFwTvUWat36513i9qn
XewCN50jf/#Z7_QVMRH7R20GFA60II95HID43007

如果一個特定引數太大，將被儲存在會話中，並且只有引用鍵被儲存在 URL 中。這有助於將 URL 保持在 2k 之下，2k 是許多瀏覽器或 HTTP 基礎設施元件（例如 proxies）強制限制的。

該解決方案的弊端是您現在不再可以手動建立引數，這是因為編碼原因。因此，Portal 為您提供上述機制，在門戶 URL 的末端新增一個簡單 URI。現在兩全其美了：您可以利用 JSR 286 公共呈現引數定義的導航狀態模式，並且您也可以輕鬆地在一個指定 URL 中設定引數。

當您將一個呈現 portlet 的 Web Content Management 從舊的 Web Content Viewer 遷移到基於 JSR 286 的新版本時，您將獲得許多新功能，像書籤設定功能，可以在 URL 中儲存選擇的上下文，然而，您似乎也失去了一個從外部應用程式向 Web Content Management 所呈現的 portlet 傳送引數的簡單方法。這篇專欄文章描述了一個簡單的方法，通過使用一個附加在 URL 中的 URI 重獲這一能力，同時也不喪失任何新功能。

原文連結：http://www.ibm.com/developerworks/cn/websphere/techjournal/1007_col_hepper/1007_col_hepper.html

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14789789/viewspace-675112/，如需轉載，請註明出處，否則將追究法律責任。