Java Portlet 的优缺点？答案

【问题标题】：Pros and cons of Java Portlets?Java Portlet 的优缺点？
【发布时间】：2009-07-18 05:43:08
【问题描述】：

我有一个项目，其中我的客户要求我使用 portlet 1.0 规范和 Websphere Portal Server 6.0。我以前没有使用过portlet，但我听说过的总是不好的批评。除了显而易见的使用它们之外，还有什么原因？如果不是原因，我可以使用哪些论据来避免它们？

【问题讨论】：

标签： java evaluation portlet

【解决方案1】：

作为一个从事过多个工作（包括我目前的工作）开发 Java portlet 的人，我会说不要使用它们。

问题来了：

如果您只想使用您选择的门户网站的现有功能，请使用门户网站。

如果您使用 portlet 只是为了构建一个小型、轻便、主要是只读的基于 Web 的仪表板，您可以在其中快速查看不同的信息，那很好。

但是，如果您（或者更有可能是组织结构图上更高的人）认为 portlet 是一种将一堆不同的 Web 应用程序放在一个页面上并让它们“正常工作”的一种方式，那么您将走向一个伤害的世界。 Portlet 是高度受限的、自包含的功能孤岛，而不是页面上小方块中的 Web 应用程序。

我的每一个基于 portlet 的工作都犯了这个错误，隧道尽头没有光明。作为一个 portlet 开发人员，这里有一小部分您习惯于在常规 Web 应用程序中做的事情，而您在 portlet 中无法可靠地做这些事情：

生成其他页面的 URL。您需要一种特定于供应商的方式来执行此操作，因为 Portlet API 只允许您生成以生成它们的 portlet 为目标的 URL。
读取和设置 HTTP 标头或设置 HTTP 响应代码（因此没有重定向或 HTTP 缓存，因为您不拥有将放置 portlet 的页面）
必须为生成的页面中的所有标识符命名。这意味着 HTML id 属性和 JavaScript 函数名称。由于必须在运行时确定名称空间以确保唯一性，因此您不能让这些 Javascript 函数驻留在单独的浏览器可缓存文件中，它们必须位于 portlet 的响应正文中。

Portlet 感觉好像它们是为 90 年代中后期（AJAX 之前）的 Web 开发状态而设计的。但它们不适合当今假设您完全控制请求/响应周期的 Web 开发环境（AJAX、单页富 Web 应用程序等）。

【讨论】：

【解决方案2】：

portlet 的问题让我想起了与 EJB 相同的问题-

portlet 要求您编写只能在特殊服务器上托管和运行的特殊代码；
每个 Portlet 服务器供应商都有自定义扩展/配置/附加功能，因此更改服务器供应商并非易事；
portlet 似乎过于复杂，无法涵盖 90% 想要使用它的人不需要的功能

我建议像 Google Gadgets 这样的东西作为 Portlet 的 EJB 的休眠 -

Javascript 框架 - 服务器端部分可以用任何语言编写，托管在任何服务器上。
使用更简单
很多门户服务器都支持它，而且它在供应商之间更容易移植，因为它没有那么复杂，而且它不是供应商实施（和扩展）的规范

【讨论】：

【解决方案3】：

Portlet 对企业很有吸引力，因为它承诺提供灵活性，您可以允许客户调整和重新排列页面上的组件，如果您主要提供内容，那么它们是一种有效的方式。

在我看来，门户网站非常适合聚合纯内容、功能独立或简单相关的 portlet（例如，当您从一个 portlet 的列表中选择一项时，您更新另一个以显示详细信息）。 Portlet 还可以实现重用，因为您可以相当简单地将它们配置到多个页面/位置。

当您尝试分解具有多个步骤和交互的复杂业务功能时，问题可能会开始。在这种情况下，确定 portlet 的粒度更像是一门艺术而非科学，需要仔细考虑 portlet 之间的交互。

您还需要考虑 UI 的灵活性。如果您有一组 portlet 构建块，您的业务需要清楚他们可以重新排列这些块，但是在 portlet 之间移动项目涉及重写。例如，将提交按钮从一个 portlet 移动到页面底部并非易事。

因此，总而言之，我想这取决于您要尝试做什么以及您对组件的预期重用程度。通过创建 IT 构建到 servlet 中的技术组件来管理重用可能更简单，或者 portlet 可能非常适合您的业务。没有正确的答案，您只需要仔细考虑您要达到的目标。如果您确实决定使用 portlet，则需要接受整个生命周期，并避免试图绕过它们，您很快就会发现自己处于一个糟糕的境地，因为 portlet 的所有开销和限制，而无法意识到其优势。

【讨论】：