6

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

4

3 回答 3

9

作为从事过几份工作（包括我目前的工作）开发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 应用程序等）。

于 2012-08-10T21:14:37.210 回答
5

Portlet 的问题让我想起了与 EJB 相同的问题——

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

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

  • Javascript 框架 - 服务器端的部分可以用任何语言编写，托管在任何服务器上。
  • 使用更简单
  • 许多门户服务器都支持它，并且它在供应商之间更具可移植性，因为它没有那么复杂，而且它不是供应商实现（和扩展）的规范
于 2009-07-18T11:15:35.350 回答
3

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

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

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

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

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

于 2009-07-18T10:23:41.633 回答