为 Liferay 开发 portlet 的限制/缺点
我正在考虑将应用程序开发为 portlet，以集成到 Liferay 门户中。 与使用 Spring 框架开发普通的 Web 应用程序相比，开发此类应用程序是否有任何明显的缺点或限制？
Liferay 似乎要求所有内容都作为 portlet 添加。 我考虑的另一个选择是仅将 Liferay 用于应用程序的某些部分，并添加指向其他自行开发内容的外部链接，将其开发为普通的 Web 应用程序。 然而，这将需要多个用户身份验证机制以及 Liferay 和其他 Web 应用程序之间的某种跨站点身份验证。
哪条路最好？
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?
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.
Which is the best way to go?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
（免责声明：我是 Liferay 的开发人员之一）
我认为这两种选择都很好，具体取决于您的需求。 如果您以前有开发独立 Web 应用程序的经验，但没有开发 portlet 的经验，那么选择前者将使您更快上手。 缺点是您必须实现自己的用户和权限系统，并且无法利用 Liferay 提供的门户服务。 如果您决定使用此替代方案，请注意，您可以将常规 WAR 文件部署到 Liferay，它将自动创建一个简单的 portlet，使用 iframe 来显示您的应用程序。 这将允许您将独立应用程序与 portlet 一起放入 Liferay 的页面中。
当您开始利用 Liferay 提供的门户服务时，为 Liferay 开发 portlet 就开始获得回报。 从开发 portlet 开始，您可以忘记开发自己的用户系统，而使用 Liferay 提供的系统（非常强大）。 您还可以使用其他服务，例如权限、评论、标记、分类、数据范围等，这将使您能够在更短的时间内开发出相当完整的应用程序。 缺点是第一次这样做时你必须学习一些新东西，但第二次你会学得更快。
我希望这有帮助。
(Disclaimer: I'm one of Liferay's developers)
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.
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.
I hope that helps.
我在内部应用程序中使用 Liferay 已有大约 2 年了。 在第一个版本发布之前，我们在整个开发周期中多次进行了相同的讨论。 我们不得不与Liferay交战几次，有时是因为我们自己知识的缺乏，有时是因为portlet环境，有时是因为Liferay。
如果您想要从门户获得多个应用程序的布局选项，那么您当然应该使用 Liferay。 如果您正在编写单个应用程序，那么我可能不会使用 Liferay。 我认为一些 Liferay 和一些非 Liferay 的混合是迄今为止最糟糕的选择。
我们可能没有充分利用 Liferay 的功能，但如果这是您的第一个 Liferay 应用程序，那么由于学习曲线的原因，您很可能也不会。 我们最初希望为应用程序的不同方面提供许多不同的 portlet，但由于在开发过程中（JSR-286 之前）缺乏良好的 portlet 间通信机制，我们最终编写了一个应用程序。 既然我们最终上了那条船，我希望我们没有 Liferay，因为我们真正使用的只是一些用户管理功能。
我们使用 JSF 和 Facelets（对我们来说都是新技术，所以痛苦可能是我们自己造成的），虽然我们在这方面做得越来越好，但为了让它正常工作，我们似乎必须跨越一些障碍正确地在 portlet 中； 这些事情在常规网络应用程序环境中是不必要发生的。 对于许多框架来说，Portlet 支持似乎是事后才想到的。 这显然不是 Liferay 特有的，它只是在 portlet 环境中工作的副产品。
在使用 Spring MVC、Struts、Faces、Wicket 等的 Web 应用程序中，您将对所有内容拥有更多控制权，同时还要负责实现更多内容。
在 portlet 中，您将受到 JSR-168 和/或 JSR-286 条款的约束。 门户容器将为您提供一些功能，例如用户身份验证，但在我看来，用于用户身份验证的整个门户太重了。 我看到门户的强大之处在于允许用户自定义多个应用程序的视图，而不是呈现单个应用程序。
您应该查看与 portlet 相关的规范，看看它是否符合您的需求。
http://developers.sun.com/portalserver/reference/techart/jsr168/
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.
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.
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.
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.
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.
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.
You should review the portlet related specs and see if it fits your needs.
http://developers.sun.com/portalserver/reference/techart/jsr168/
Liferay 是一个非常强大的系统，有许多现成的服务和应用程序，但最大的缺点是缺乏文档。 仅仅看代码是不可能知道所有事情的，所以在我看来，如果你没有专业知识，就不要选择 Liferay。
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 和 portlet 一般而言非常适合特定类别的应用程序。 如果您在 IT 部门工作并且需要为多个部门或由多个部门组合应用程序，那么 portlet 将是最佳选择。 理论上，您可以放入来自不同供应商的 portlet，它们将在同一环境中和谐共处。
但是，如果您正在构建以下任一应用程序：
1) 完全由单个团队创建
2) 需求有单一来源
3) 具有不属于 Portlet 容器中可用功能子集的要求。
4) 图形设计师不愿意生活在门户风格应用程序的范围内。
那么坚持像 Spring 这样的东西就是正确的选择。
Spring 及其许多子项目提供了 portlet 提供的许多共享服务和基础设施，但它们是以开放且更灵活的方式提供的。 您可以挑选并选择您想要的。
Portlet 在身份验证和授权、导航和布局方面为您做出许多设计决策。 如果您为应用程序制定的计划超出了这些决定，您将花费大量时间创建变通办法来尝试让它执行您想要的操作。
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.
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.
then sticking with something like Spring would be the way to go.
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.
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.
请大家不要将此视为恶搞/煽动。 我认为 Liferay 社区应该解决这个问题，每个考虑使用 Liferay 的人都应该知道。
缺点：没有文档。 没有什么比 Hibernate 的文档更遥远的了。 只是一个空的javadock（代码中没有注释），一些在论坛和旧版本书籍中回答的问题（无用）。
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.
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).
我一直认为像 Liferay 这样的门户应该被视为类似于共享基础设施。 它们提供了访问应用程序、共享服务（例如身份验证）的通用方法和标准部署方法，但以性能为代价。
如果您打算将不仅仅是此应用程序部署到门户中，那么，是的，这可能是合适的，因为您无需再次开发这些共享服务，从而节省时间/成本。 后续应用程序的外观和行为方式将与此类似。
但是，如果这是唯一要部署的应用程序，那么门户网站的开销并不值得，您最好使用普通的 Web 应用程序。
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.
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.
Liferay 具有 CMS 功能，可以与 Alfresco 等外部 CMS 平台集成。
Liferay has CMS functionality and can integrate with external CMS platforms such as Alfresco.
伙计，看看这个解决方案 Netbeans IDE + PoralPack3.0 插件 + Liferay 5.2 捆绑包。 这里的 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
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.
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