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应用程序等），它们假设您完全控制了请求/响应周期。