Restrictions/disadvantages of developing portlets for Liferay [closed]

Question

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?

Subrogation

Answer 1

(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.

Magog

Answer 2

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/

Creditor

Answer 3

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.

Tinder

+1 for lack of documentation, Liferay is terrible for documentation. – Zenda

Answer 4

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.

Bronchiectasis

Answer 5

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).

Ethos

well - had this answer been a year old, I'd agree somewhat, but if you follow the documentation efforts, this has changed a lot during this time. Documentation on liferay.com/de/documentation is revamped, wiki and forum are quite active. It's a complex system, documentation can always be improved, but it also has done so a lot. The problem is that you need to understand way more than in hibernate if you get into development and other details. Yes, there's no javadoc - but the code follows strict coding standards, so there is a way to read & understand it if you get used to this. – Kizzie

Even if the code follows strict coding standards, a total lack of Javadoc on any system reflects poor management and architecture, or (alternatively) that the code base is not designed to be modified or understood at all. – District

Answer 6

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.

Yesseniayester

I would hope if they are really 'shared' services, you wouldn't have to write them a second time anyway. There would be some integration effort, but it should be much smaller than implementing it a second time. – Creditor

Answer 7

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

Morgun

Answer 8

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

Prescience

The juice of Liferay is - 1. you are able to focus on the pure business logic leaving all low level stuff to the LR; 2. All LR functionalities are customizable and you are able to create your own fully compatible portlets. – Prescience