Java Portlets的優缺點？

Question

我有一個項目，其中我的客戶要求使用portlets 1.0規範和Websphere Portal Server 6.0。我以前沒有使用portlet，但是我聽說過他們一直是糟糕的批評。除了顯而易見的使用它們的原因是什麼？如果不是理由，我可以用什麼論據來避免它們？

Answer 1

我有門戶的問題，讓我想起了同樣的問題EJBs-

• 的portlet要求你寫只能託管特殊的代碼，並在特殊的服務器上運行;
• 每個Portlet服務器供應商都有自定義的擴展/配置/附加功能，因此改變服務器供應商並不是微不足道的;
• 門戶似乎是過於複雜的支付功能，90％的人想用它不需要

我建議像Google Gadgets爲Hibernate來portlet的EJB -

• Javascript框架 - 服務器端部分可以用任何語言編寫，託管在任何服務器上。
• 易於使用
• 很多門戶服務器的支持，它的跨廠商更便攜，因爲它不是那麼複雜，它不是廠商來實現規範（伸）

Answer 2

由於靈活性的承諾，您允許客戶調整和重新排列頁面上的組件，並且如果您主要提供內容，Portlet對業務具有吸引力，因此它們是實現這一目標的有效手段。

在我看來，門戶非常適合聚集純內容，功能獨立或簡單相關的portlet（例如，當您從一個portlet中的列表中選擇一個項目，並更新另一個以顯示細節時）。 Portlet也可以重用，因爲您可以簡單地將它們配置爲多個頁面/位置。

問題可以開始的地方是當您試圖通過多個步驟和交互來分解複雜的業務功能時。在這種情況下，確定portlet的粒度更多的是藝術而不是科學，並且需要仔細考慮portlet之間的交互。

您還需要考慮UI的靈活性。如果您有一組portlet構件塊，則您的業務需要清楚說明它們可以重新排列這些塊，但在portlet之間移動項目需要重寫。例如，將提交按鈕從一個portlet移動到頁面底部並不重要。

總之，我想這取決於你想要做什麼以及你對組件的預期複用程度。通過創建IT構建到servlet中的技術組件來管理重用可能會更簡單，或者可能是portlet對於您的業務來說是完美的。沒有正確的答案，你只需要仔細考慮你想達到的目標。如果您決定使用portlet，那麼您需要接受整個生命週期，並且避免任何繞開它們的誘惑，您可以快速發現自己處於一個糟糕的境地，無法體會到這些優勢，因爲它具有所有portlet的開銷和限制。

Answer 3

正如有人誰有幾個工作（包括我現在的）正在開發Java portlet，我說不要使用它們。

這裏的問題：

如果你只是想利用門戶的預先存在的功能，您選擇，然後使用一個門戶。

如果您使用portlet只是爲了構建一個小的，輕的，主要是隻讀的基於Web的儀表板，您可以快速查看不同的信息，那就沒問題。

但是，如果您（或者更有可能是組織結構圖上的某個人）認爲portlet是一種將大量不同的Web應用程序放在頁面上並將其全部「正常工作」的方法，那麼您將前往一個受傷的世界。 Portlet是高度受限的自包含功能的島嶼，而不是網頁上的小方塊中的Web應用程序。

我的每一個基於portlet的工作都犯了這個錯誤，隧道盡頭沒有燈光。作爲portlet開發人員，以下列出了您在常規Web應用中常用的一些內容，您無法在portlet中可靠地進行操作：

• 生成到其他頁面的URL。您需要特定於供應商的方式來執行此操作，因爲Portlet API只允許生成針對生成它們的portlet的URL。
• 讀取並設置HTTP標頭或設置HTTP響應代碼（因爲您不擁有portlet將要放置的頁面，因此不需要重定向或HTTP緩存）
• 必須在生成的頁面中命名空間所有標識符。這意味着HTML ID屬性和JavaScript函數名稱。由於必須在運行時確定命名空間以確保唯一性，因此您不能將這些Javascript函數駐留在單獨的可瀏覽器緩存文件中，因此它們必須位於portlet的響應正文中。

Portlets感覺好像它們是爲了網頁開發的狀態而設計的，就像在90年代中後期（AJAX之前）一樣。但是它們不適合當今的Web開發環境（AJAX，單頁富Web應用程序等），它們假設您完全控制了請求/響應週期。