Alternative Languages: 日本語

Introduction #

Liferay portal is extensible at least at three levels: Plugins SDK environment, extension environment and Liferay portal source code. In general, each level of extensibility offers a different compromise of flexibility with different migration requirements to future version. This document will discuss development strategies.

Extension Environment #

The Extension environment provides capability to customize Liferay portal completely. Since it is an environment which extend Liferay portal development environment, it have a name “Extension”, or called “Ext”. By the Ext, we could modify internal portlets, or called the out-of-the-box portlets. Moreover, we could override the JSP files of portal and out-of-the-box portlets. This kind of customizations is kept separate from the Liferay portal source code. That is, Liferay portal source code does not have to be modified, and a clear upgrade path is available in the Ext.

As shown in following figure, custom code will override Liferay portal source code in the Ext only. In deployment process, custom code is merged with Liferay portal source code in the Ext. That is, developers override Liferay portal source code. Moreover, custom code and Liferay portal source code will constructed as customized Liferay portal in the Ext first, and then the customized Liferay portal will be deployed from the Ext to the application server.

Abstracted from the book:Liferay-Portal-5-2-Systems-Development

During customization, we could use the Service Builder to generate models and services. In general, the Service Builder is a code generator, using an XML descriptor. For a given xml file service.xml, it will generate SQL for creating tables, Java Beans, Hibernate configuration, spring configuration, Axis Web Service and JSON JavaScript Interface, etc.

JSP files of the portal and the out-of-the-box portlets can be overridden with custom versions in the Ext. Note that, the Ext is used for customizing Liferay portal only, since portlets written in the Ext are not hot deployable, and moreover, the Ext is a monolithic environment.

Plugins SDK Environment #

The Plugins SDK is a simple environment for the development of Liferay plugins, including themes, layout templates, portlets, hooks and webs (that is, web applications). It provides capability to create hot-deployable portlets, themes, layout templates, hooks and webs.

How does it work? As shown in following figure, the Plugins SDK provides environment for developers to build themes, layout templates, portlets, hooks or webs first. Afterwards, it uses the Ant target Deploy to form WAR and copy it to the Auto Deploy directory. Then, Liferay portal together with application server will detect any WAR files in the auto hot-deploy folder, and automatically extracts the WAR files into the application server deployment folder.

Abstracted from the book:Liferay-Portal-5-2-Systems-Development

For more details, portlets go in the folder /portlets; themes go in the folder /themes; layout templates go in the folder /layouttpl; web applications go in the folder /webs; and hooks go to the folder /hooks. By the way, Ant scripts are used to build and deploy plugins to a local application server.

Especially, portlets developed in the Plugins SDK may only import classes from the portal API (Portal-Kernel and Portal-Service) and other JAR files contained in the specific portlet folder /WEB-INF/lib. This forces portlets to rely completely on the Portal API and not to depend on implementation classes defined in the Portal-Impl.

As you can see, portlets can make use of any application framework that Liferay supports, Model-View-Controller (MVC) frameworks. Here is a list of application frameworks, but not limited, Struts, Spring, Tapestry, JSF, Wicket, etc.

In addition, as mentioned above, Liferay portal can also integrate with certain web applications as webs, for instance, solr-web - search engine integration plugin; jbpm-web – workflow engine integration plugin; mule-web and servicemix-web - Enterprise Service Bus (ESB) integration plugins.

Development Strategies #

As mentioned earlier, there are at least two development environments: the Ext and Plugins SDK. Thus, which kind development environment is suitable for our requirements you may ask? When should we use the Ext and when should we use Plugins SDK or even Liferay portal source code? Let’s have a deep look on the development strategies.

As shown in following figure, Liferay Portal is extensible at least at three levels, e.g. Plugins SDK environment (Level I), Extension environment (Level II) and Liferay Portal Source Code (Level III). As you can see, each level of extensibility offers a different compromise of flexibility with different migration requirements to future version. Thus, we need to choose the appropriate level for the requirements at hand which allows for easier future maintainability.

Abstracted from the book: Liferay-Portal-5-2-Systems-Development

In the Level I, we can develop portlets, themes, layout templates, hooks and webs as independent software components, and moreover, these plugins could be distributed and deployed as WAR files and could be organized in plugin repositories. Liferay portal provides the Plugins SDK to help us with development of these plugins.

In addition, portlets developed in the Plugins SDK can only import classes from the portal API (Portal-Kernel and Portal-Service), not the Portal-Impl. That is, portlets development in Plugins SDK does not even touch portal properties, language properties and JSP files related to the Portal-Impl. Fortunately, Hooks provides capability to hook up portal properties, language properties and JSP files related to the Portal-Impl.

In the Level II, we can manage configuration files, custom source code, custom JSP files, and modified JSP files, related to the Portal-Impl. That is, the Ext provides different sub-levels (e.g., configuration files, custom source code, custom JSP files, and modified JSP files) of extensibility.

For configuration files, portal-ext.properties is main configuration options: layouts, deployment, themes, Hibernate, cache, instance settings, users, groups, language, session, auth, integration, events, etc. Meanwhile, system-ext.properties is convenient way to provide and extend the Java System properties used by Liferay portal. We can also create custom classes for the most common extensibility which needs configurable through portal.properties, e.g. authentication chain, upgrade and verification processes, deployment processes, database access and caching, user fields generation and validation, session events, permissions, model listeners, etc.

For custom source code, we can use Spring based dependency injection mechanisms - configured in ext-spring.xml; add the Servlet - extended in web.xml; add the Struts action - extended in struts-config.xml; and moreover, create portlets – accessing to the Portal-Impl or event extending models and services in the Portal-Impl.

For custom JSP files and modified JSP files, we can customize any of the JSP files used by the out-of-the-box portlets and management tools. This is a very flexible extension mechanism.

Without a doubt, it is easier to develop portlets in the Ext. Using the Ext, you can get easily to all Liferay Portal API, taglib, JSP files and almost everything. And this is not the case in the Plugins SDK at the time of writing.

In the Level III, we can modify the Liferay portal source code. This approach can only be used for sponsored development. That is, we develop specific features for specific projects first and then contribute back to Liferay portal source code.

In brief, if your requirements are related to customize and / or extend the Portal-Impl (e.g. UI changing, LDAP import algorithms, Document Library lock mechanism, forms for user registration or organization creation, integration, modifying the out-of-the-box portlets, etc.), you should use the Ext. Otherwise, it is better to use Plugins SDK. Note that with Hooks you can hook up portal properties, language properties and JSP files related to the Portal-Impl.