Java Portlets的优点和缺点？

Question

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

Answer 1

作为有多个工作（包括我当前的工作）开发Java portlet的人，我会说不要使用它们。

问题在于：

如果您只想使用您选择的门户网站的预先存在的功能，请使用门户网站。

如果您使用portlet只是构建一个小型，轻量级，主要是只读的基于Web的仪表板，您可以快速查看不同的信息，那就没关系。

但是如果你（或者更有可能是组织结构图上的某个人）认为portlet是一种在网页上放置一堆不同的网络应用程序并将其全部“正常工作”的方法，那么你就会前往受伤的世界。 Portlet是高度受限制的，独立的功能岛，而不是页面上的小方块中的Web应用程序。

我的每个基于portlet的作业都犯了这个错误，并且在隧道尽头没有任何亮点。作为一个portlet开发人员，这里有一些你曾经常常在常规Web应用程序中做的事情，你无法在portlet中做到这一点：

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

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

Answer 2

我对portlet的问题让我想起了与EJBs-

相同的问题

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

我建议将Google Gadgets作为Hibernate to portlet的EJB -

• Javascript框架 - 服务器端部分可以用任何语言编写，托管在任何服务器上。
• 更易于使用
• 许多门户服务器支持它，并且它在各个供应商之间更具可移植性，因为它并不复杂，并且它不是供应商实施（和扩展）的规范

Answer 3

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

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

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

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

总而言之，我想这取决于您尝试做什么以及您预期组件的重用次数。通过创建IT构建到servlet的技术组件来管理重用可能更简单，或者可能是portlet非常适合您的业务。没有正确的答案，你只需要仔细考虑你想要实现的目标。如果您决定使用portlet，那么您需要拥抱完整的生命周期，并避免任何解决它们的诱惑，您可以快速找到自己处于一个不利于Portlet的所有开销和限制的地方，而无法实现这些优势。