Developing applications for Liferay

According to Wikipedia "A web application is an application that is accessed over a network such as the Internet or an intranet.". A portal application is a web application that can cohexist with many other applications in a civilized way and also that can reuse many functionalities provided by the portal platform to reduce the development time and deliver a more consistent experience to end users.

If you are reading this, you probably want to (or need to) develop an application that runs on top of Liferay Portal. And you might be looking for an answer to the question of what is the best and quickest way to do it? Liferay provides two main ways to develop applications, and both are based on standards:

• Portlets: portlets are small web applications written in Java that follow a certain set of rules to allow cohabitation within the same portal or even within the same page. Portlets can be used to build applications as complex as you want since the full suite of technologies and libraries for the Java platform can be used.

• OpenSocial Gadgets: gadgets are usually small applications, written using browser side technologies such as HTML and Javascript. One interesting benefit of gadgets is that they are easy to develop and for that reason there are thousands of them in repositories such as iGoogle's repository. When the application becomes more complicated you will need a complementary backend technology, such as portlets or regular Java web applications.

The following sections describe these options with some more detail.

Portlets

Portlets are small web applications written in Java that run in a portion of a web page. The heart of any portal implementation is its portlets, because they contain the actual functionality. The portlet container is only responsible for aggregating the set of portlets that are to appear on any particular page.

Portlets are the least invasive form of extension to Liferay, as they are entirely self contained. Consequentially portlets are also the the most forward compatible development option. They are hot-deployed as plugins into a Liferay instance, resulting in zero downtime. A single plugin can contain multiple portlets, allowing you to split up your functionality into several smaller pieces that can be arranged dynamically on a page. Portlets can be written using any of the java web frameworks that support portlets development, including Liferay's specific frameworks: MVCPortlet or AlloyPortlet.

OpenSocial Gadgets

Like portlets, OpenSocial Gadgets are an standard way to develop applications for a portal environment. From a technology perspective one key difference is that they don't mandate an specific backend technology, such as JavaEE, PHP, Ruby, Python, etc. Another difference is that it has been designed specifically to implement social applications, while portlets were designed any type of application. Because of this, OpenSocial Gadgets, not only provide set of technologies to develop and run applications but also a set of APIs that allow the application to obtain information from the social environment such as information about the user profile, his activities or his friends.

It is possible to deploy OpenSocial Gadgets in Liferay in one of two ways:

• Remote Gadget: A remote gadget is one that is executed in a remote server but is shown to the user in a given page just as if it was another application of the platform. This option is very simple but has the drawback that the portal depends on the remote server for that gadget to work. This might not even be an option in some intranet environments in which there isn't full access to Internet.

• Local Gadget: consists in deploying the gadget in the Liferay server in the similarly as portlets are deployed. Gadgets are defined as an XML file so all you need to do is to upload that file to the server. Some people like to upload them directly through the file system, FTP or similar protocols. In some other cases, just uploading it with theDocument Library portlet and copying the URL is enough. Once you have the URL you can go to the Control Panel > OpenSocial, click the "New Gadget" button and enter the URL as shown in the following screenshot:

After this is done, the gadget will appear as an application that page administrators can add to their pages.

One additional very interesting feature of the latest versions of Liferay is that it is possible to expose any application developed as portlets, as OpenSocial gadgets to the outside world. That is, you can develop a portlet and then let anyone with access to your portlet to add it to the pages of other portals or social networks as a remote gadget.

Note that since an OpenSocial gadget is defined in an XML file, there is no need to create a plugin (that is a .war file) in order to deploy it. All you need to do is make that XML file accessible within the same or another server and let Liferay know the URL.

Reusing existing web applications

Sometimes you don't start from scratch, but there is an existing application that already exists and which has not been implemented using Portlets or OpenSocial Gadgets. What can you do in that situation? There are many options available. Some of the most popular are:

• Rewrite your application as a portlet

• Create simple portlets that interact with your application (possibly using Web Services) and offer all or part of the functionality to end users.

• Create an OpenSocial gadget as a wrapper for your application. The Gadget will use an Iframe to show part of your application in the portal page.

• Create a portlet that integrates the remote application either using an iframe or an HTTP proxy (For example using Liferay's WebProxy portlet). You will also need to find a way to achieve transfer the authentication between the portal and your application.

There are many more options and many reasons why you may want to choose one or another. Reviewing each of them is out of the scope of this guide.

If the existing application has been developed as a JavaEE application, Liferay provides a technology caled Web Application Integrator that allows prototyping the integration and provides several nice features.

In order to use Web Application Integrator all you need to do is deploy the WAR file of your web application as you would do with any Liferay plugin (for example, by using the control panel or by copying it to the deploy directory). As a result Liferay will automatically create a portlet that integrates your application using an iframe.

Supported Technologies

Liferay as a platform strives to provide compatibility with all Java technologies that a developer may want to use to develop their own applications. Thanks to the portlet and the JavaEE specifications each portlet application can use its own set of libraries and technologies regardless of whether they are what Liferay uses itself or not. This section refers mainly to portlet plugins, other plugin types are more restricted. For example the ext plugins can only use libraries that are compatible with the ones used by the core Liferay code.

Since the choice of available frameworks and technologies is very broad, the task can be daunting to newcomers. This section attempts to provide some advice to help developers choose the best tools for their needs. This advice can be grouped in three:

• • Use what you know: If you already know a framework, that can be your first option (Struts 2, Spring MVC, PHP, Ruby...)

  • Adapt to your real needs: Component based frameworks (JSF, Vaadin, GWT) are specially good for desktop-like applications. MVC frameworks on the other hand provide more flexibility.

  • When in doubt, pick the simpler solution: Portlet applications are often much simpler than standalone web applications, so, when in doubt use simpler frameworks. (MVC Portlet, Alloy Portlet)

Some of the frameworks mentioned above include their own JavaScript code to provide a very high degree of interaction. That is the case of GWT, Vaadin or JSF implementations such as IceFaces or Rich Faces. In other cases the developers prefer to write their own JavaScript code. In such cases it's most often recommended to use one of the available JavaScript libraries. Some of the most common libraries that can be used with Liferay are jQuery, Dojo, YUI, Sencha (previously known as ExtJs), Sproutcore, etc. Starting with version 6, Liferay also provides its own library called AlloyUI which is based on YUI 3 and provides a large set of components specifically designed for very efficient and interactive applications that work well in portal environments. Liferay's core portlets use AlloyUI for all Javascript code. Developers can also use AlloyUI for their custom portlets or choose any other JavaScript library as long as they make sure that it will not create conflicts with the code of other portlets deployed in the same portal.

Besides the frameworks and libraries mentioned in this section, there are literally thousands more available to Java developers to handle persistence, caching, connections to remote services, and much more. Liferay does not impose specific requirements on the use of any of those frameworks so that portal developers can choose the best tools for their projects.