Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Restrictions/disadvantages of developing portlets for Liferay [closed]

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?

like image 901
simon Avatar asked May 08 '09 08:05

simon


People also ask

What are the advantages of Liferay Portal?

Liferay Portal's impressive ease-of-use has been integral to the product's popularity. With just a few clicks, you can make changes to the look and feel, portlet configurations, themes, and page layouts. With a simple drag-and-drop, you can add and reposition applications, tools and other elements to the portal.

Are portlets still used?

Today, it is often used in mobile applications, social networking Web sites, mashup tools and now increasingly, in Portals. Essentially, Representational State Transfer is an architectural style which makes the most of existing protocols and technologies, including HTTP, JSON and XML.


2 Answers

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

like image 113
user104936 Avatar answered Sep 20 '22 15:09

user104936


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/

like image 43
digitaljoel Avatar answered Sep 19 '22 15:09

digitaljoel