java 为 Liferay 开发 portlet 的限制/缺点

Restrictions/disadvantages of developing portlets for Liferay

提问by simon

I'm considering developing an application as portlets, to be integrated in Liferay portal. Are there any significant disadvantages or restrictions in developing such an application, as opposed to developing a normal web application using Spring framework?

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

Liferay seems to require that all content is added as portlets. Another option I ponder is to use Liferay just for some parts of the application and add external links to other self-developed content, developed as a normal web application. That would, however, create a need of multiple user authentication mechanisms and some kind of cross-site authentication between Liferay and the other web application.

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

Which is the best way to go?

最好的方法是什么？

采纳答案by user104936

(Disclaimer: I'm one of Liferay's developers)

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

I think both options are good depending on your needs. If you have previous experience developing standalone web applications but no experience developing portlets, then picking the former will get you started faster. The drawbacks would be that you would have to implement your own users and permissions system and would not be able to leverage the portal services provided by Liferay. If you decide to use this alternative, note that you can deploy regular WAR files to Liferay and it will automatically create a simple portlet that uses an iframe to show your app. This will allow you to put the standalone app along with the portlets in Liferay's pages.

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

Developing a portlet for Liferay starts to pay off when you start leveraging the portal services it provides. To start with by developing a portlet you can forget about developing your own user system and use the one that Liferay provides (which is quite powerful). You can also use other services such as permissions, comments, tagging, categorization, data scoping, etc. which will allow you to develop pretty complete application in a shorter time. The drawback is that the first time you do this you'll have to learn several new things, but the second time you'll go much faster.

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

I hope that helps.

我希望这有帮助。

回答by digitaljoel

I've been using Liferay for about 2 years now for an internal application. We had the same discussion many times throughout the development cycle before our first release. We had to fight Liferay a few times, sometimes because of our own lack of knowledge, sometimes because of the portlet environment, and occasionally because of Liferay.

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

If you want the layout options for multiple applications that you can get from a portal, then you should certainly use Liferay. If you are writing a single application, then I would probably not use Liferay. I think a hybrid of some Liferay and some not is by far the worst option.

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

We are probably not leveraging Liferay to its fullest capabilities, but if this is your first Liferay app, then chances are you won't either because of the learning curve. We originally hoped to have many different portlets for the different aspects of our application, but due to a lack of good inter-portlet communication mechanisms during development ( pre JSR-286 ) we ended up writing a single application. Now that we ended up in that boat, I wish we had gone without Liferay since all we are really using is some user management capabilities.

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

We use JSF and facelets (both new technologies to us, so the pain may have been self inclicted) and while we've gotten better at it, it seems like there were a few hoops we had to jump through in order to get it working correctly in a portlet; Things that wouldn't have had to happen in a regular web-app environment. For many frameworks, it seems that portlet support is an afterthought. This is obviously not Liferay specific, it's just a byproduct of working within the portlet environment.

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

In a webapp using Spring MVC, Struts, Faces, Wicket, whatever, you are going to have a lot more control over everything, but also be responsible for implementing more stuff.

在使用 Spring MVC、Struts、Faces、Wicket 等的 web 应用程序中，您将拥有更多的控制权，同时还要负责实现更多的东西。

In a portlet, you are going to be subject to the terms of JSR-168 and/or JSR-286. The portal container will provide some functionality for you, like user authentication, but IMO, an entire portal for user authentication is way too heavy. I see the power of the portal being allowing the user to customize their view of multiple applications, not presenting a single application.

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

You should review the portlet related specs and see if it fits your needs.

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

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

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

回答by user199471

Liferay is a extremely powerful system, there are many services and applications which are available ready made but the biggest drawback is the lack of documentation. It impossible to know everything just looking at the code, So in my opinion if you dont have the expertise dont go for Liferay.

Liferay 是一个非常强大的系统，有许多现成的服务和应用程序可用，但最大的缺点是缺乏文档。仅查看代码不可能了解所有内容，因此在我看来，如果您没有专业知识，请不要选择 Liferay。

回答by Jason

Liferay and portlets in general are great for a very specific class of applications. If you are working for an IT department and need to combine apps for or by several departments then portlets would be the way to go. In theory you can drop in portlets from different venders and they will all live in harmony inside of the same environment.

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

However if you are building an application that is any of the following

但是，如果您正在构建符合以下任一条件的应用程序

1) created entirely by a single team 2) has a single source for the requirements 3) has requirements that aren't a subset of the features available in the portlet container. 4) has a graphic designer that isn't willing to live within the confines of portal style applications.

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

then sticking with something like Spring would be the way to go.

然后坚持使用 Spring 之类的东西将是要走的路。

Spring and its many sub-projects provide a lot of the shared services and infrastructure offered by portlets but they are offered in an open and more flexible way. You can pick and choose what you want.

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

Portlets make a lot of the design decisions for your in terms of authentication and authorization, navigation and layout. If the plans you have for your application fall outside of those decisions you will spend a lot of time creating workarounds to try and get it to do what you want.

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

回答by Bloodboiler

Everybody, please do not take this as trolling/flaming. This is something I feel Liferay community should address and everyone thinking of using Liferay should know.

大家，请不要将此视为拖钓/燃烧。这是我觉得 Liferay 社区应该解决的问题，每个考虑使用 Liferay 的人都应该知道。

Disadvantage: No documentation. Nothing even remotely like e.g., documentation of Hibernate. Just an empty javadock (no comments in code), some answered questions in forums and books for old versions (useless).

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

回答by Damo

I've always thought that Portals such as Liferay should be considered as akin to a shared infrastructure. They provide a common way to access applications, shared services (eg. authentication) and a standard way of deployment, but at the cost of performance.

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

If you intend to deploy more than just this application into the Portal then, yes, it's probably appropriate as you'll get time/cost savings from not having to develop those shared services a second time. And subsequent applications will look and behave in a similar fashion to this one.

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

However, if this is the only app to be deployed then the overhead of the Portal is not really worth it and you're better off going with a normal web application.

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

回答by McGovernTheory

Liferay has CMS functionality and can integrate with external CMS platforms such as Alfresco.

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

回答by McGovernTheory

Man, check out this solution Netbeans IDE + PoralPack3.0 plugin + Liferay 5.2 bundle. The Portal Pack here helps you by providing a nice GUI editor for service.xml file where you can define the entities or database structures and from the same GUI you can generate the services code which can be used inside your portlet.

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

For more info check the below given link: http://www.liferay.com/web/satyaranjan/blog/-/blogs/portal-pack-:-write-database-portlet-using-service-builder-plug-in

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