为 Liferay 开发 portlet 的限制/缺点 [关闭]

Posted 2023-02-23

【中文标题】为 Liferay 开发 portlet 的限制/缺点 [关闭]

【英文标题】：Restrictions/disadvantages of developing portlets for Liferay [closed]

【发布时间】：2010-10-24 17:43:36

【问题描述】：

我正在考虑将应用程序开发为 Portlet，以集成到 Liferay 门户中。与使用 Spring 框架开发普通 Web 应用程序相比，开发此类应用程序是否有任何明显的缺点或限制？

Liferay 似乎要求所有内容都作为portlet 添加。我考虑的另一个选择是仅将 Liferay 用于应用程序的某些部分，并添加到其他自开发内容的外部链接，作为普通 Web 应用程序开发。但是，这将需要多种用户身份验证机制以及 Liferay 和其他 Web 应用程序之间的某种跨站点身份验证。

最好的方法是什么？

【参考方案1】：

（免责声明：我是 Liferay 的开发人员之一）

我认为这两种选择都不错，具体取决于您的需求。如果您以前有开发独立 Web 应用程序的经验，但没有开发 portlet 的经验，那么选择前者会让您更快地开始。缺点是您必须实现自己的用户和权限系统，并且无法利用 Liferay 提供的门户服务。如果您决定使用此替代方案，请注意您可以将常规 WAR 文件部署到 Liferay，它会自动创建一个使用 iframe 显示您的应用程序的简单 portlet。这将允许您将独立应用程序与 Portlet 一起放在 Liferay 的页面中。

当您开始利用 Liferay 提供的门户服务时，为 Liferay 开发一个 portlet 就开始获得回报。从开发一个portlet 开始，您可以忘记开发您自己的用户系统，而使用Liferay 提供的那个（它非常强大）。您还可以使用其他服务，例如权限、cmets、标记、分类、数据范围等，这将使您能够在更短的时间内开发出相当完整的应用程序。缺点是第一次这样做你必须学习一些新东西，但第二次你会走得更快。

希望对你有帮助。

【参考方案2】：

我已经使用 Liferay 大约 2 年了，用于内部应用程序。在我们第一次发布之前，我们在整个开发周期中多次进行了相同的讨论。我们不得不和Liferay打了几次，有时是因为我们自己缺乏知识，有时是因为portlet环境，有时是因为Liferay。

如果您想要从门户获得的多个应用程序的布局选项，那么您当然应该使用 Liferay。如果您正在编写单个应用程序，那么我可能不会使用 Liferay。我认为一些 Liferay 和一些不是 Liferay 的混合体是迄今为止最糟糕的选择。

我们可能没有充分利用 Liferay 的功能，但如果这是您的第一个 Liferay 应用程序，那么由于学习曲线的原因，您很可能也不会这样做。我们最初希望为应用程序的不同方面提供许多不同的 portlet，但由于在开发过程中（JSR-286 之前）缺乏良好的 portlet 间通信机制，我们最终编写了一个应用程序。既然我们最终上了那条船，我希望我们没有 Liferay，因为我们真正使用的只是一些用户管理功能。

我们使用 JSF 和 facelets（对我们来说都是新技术，所以痛苦可能是自找的），虽然我们在这方面做得更好，但似乎我们必须跳过一些障碍才能让它在 portlet 中正常工作；在常规 Web 应用程序环境中不会发生的事情。对于许多框架来说，portlet 支持似乎是事后才想到的。这显然不是 Liferay 特有的，它只是在 portlet 环境中工作的副产品。

在使用 Spring MVC、Struts、Faces、Wicket 等的 web 应用程序中，您将对所有内容拥有更多控制权，但也需要负责实现更多内容。

在 portlet 中，您将受到 JSR-168 和/或 JSR-286 条款的约束。门户容器将为您提供一些功能，例如用户身份验证，但是 IMO，用于用户身份验证的整个门户太重了。我看到门户的强大之处在于允许用户自定义多个应用程序的视图，而不是呈现单个应用程序。

您应该查看与 portlet 相关的规范，看看它是否符合您的需求。

http://developers.sun.com/portalserver/reference/techart/jsr168/

【参考方案3】：

Liferay 是一个非常强大的系统，有许多现成可用的服务和应用程序，但最大的缺点是缺乏文档。仅仅看代码不可能知道一切，所以在我看来，如果你没有专业知识，就不要选择 Liferay。

【讨论】：

+1 缺少文档，Liferay 文档很糟糕。

【参考方案4】：

Liferay 和 portlet 通常非常适合特定类别的应用程序。如果您在 IT 部门工作并且需要为多个部门或由多个部门组合应用程序，那么 Portlet 将是您的最佳选择。从理论上讲，您可以从不同的供应商那里下载 portlet，它们将在同一个环境中和谐相处。

但是，如果您正在构建的应用程序属于以下任何一种情况

1) 完全由一个团队创建 2) 有单一的需求来源 3) 具有不属于 portlet 容器中可用特性子集的需求。 4) 有一个不愿意生活在门户样式应用程序范围内的图形设计师。

然后坚持使用像 Spring 这样的东西将是要走的路。

Spring 及其许多子项目提供了许多由 portlet 提供的共享服务和基础设施，但它们是以开放和更灵活的方式提供的。你可以挑选你想要的。

Portlet 在身份验证和授权、导航和布局方面为您做出了很多设计决策。如果您为您的应用程序制定的计划超出了这些决定，您将花费大量时间创建变通方法来尝试让它做您想做的事情。

【参考方案5】：

大家，请不要把这当成是拖钓/燃烧。这是我觉得 Liferay 社区应该解决的问题，每个想使用 Liferay 的人都应该知道。

缺点：没有文档。甚至没有什么比 Hibernate 的文档更远。只是一个空的 javadock（代码中没有 cmets），论坛和旧版本书籍中的一些回答问题（没用）。

【讨论】：

好吧 - 如果这个答案已经有一年了，我会有点同意，但如果你按照文档的努力，这在这段时间里发生了很大的变化。 liferay.com/de/documentation 上的文档已修改，wiki 和论坛非常活跃。这是一个复杂的系统，文档总是可以改进的，但它也做了很多。问题是，如果您进入开发和其他细节，您需要比在休眠中了解更多。是的，没有 javadoc - 但代码遵循严格的编码标准，所以如果你习惯了，就有办法阅读和理解它。

即使代码遵循严格的编码标准，任何系统上完全缺乏 Javadoc 都反映了管理和体系结构不善，或者（或者）代码库根本不是为了修改或理解而设计的。

【参考方案6】：

我一直认为 Liferay 等门户应该被视为类似于共享基础架构。它们提供了访问应用程序、共享服务（例如身份验证）和标准部署方式的通用方式，但以性能为代价。

如果您打算在门户中部署的不仅仅是这个应用程序，那么，是的，这可能是合适的，因为您不必再​​次开发这些共享服务，从而节省时间/成本。后续应用程序的外观和行为将与此类似。

但是，如果这是唯一要部署的应用程序，那么门户网站的开销并不值得，您最好使用普通的 Web 应用程序。

【讨论】：

我希望如果它们真的是“共享”服务，那么无论如何您都不必再编写它们了。会有一些整合工作，但应该比第二次实施要小得多。

【参考方案7】：

Liferay 具有 CMS 功能，可以与 Alfresco 等外部 CMS 平台集成。

【参考方案8】：

伙计，看看这个解决方案 Netbeans IDE + PoralPack3.0 plugin + Liferay 5.2 bundle。这里的 Portal Pack 通过为 service.xml 文件提供一个很好的 GUI 编辑器来帮助您，您可以在其中定义实体或数据库结构，并且您可以从同一个 GUI 生成可以在您的 portlet 中使用的服务代码。

有关更多信息，请查看以下给出的链接： http://www.liferay.com/web/satyaranjan/blog/-/blogs/portal-pack-:-write-database-portlet-using-service-builder-plug-in

【讨论】：

Liferay 的精华在于 - 1. 你可以专注于纯粹的业务逻辑，将所有低级的东西留给 LR； 2. 所有 LR 功能都是可定制的，您可以创建自己的完全兼容的 portlet。