Systems development

Liferay is, first and foremost, a platform where you can build your applications with the tools you feel most comfortable using, such as JSF 2 - ICEfaces, Struts 2, Spring 3 MVC, Vaadin, jQuery, Wicket, Dojo and more.

When developing systems, the Model View Controller (MVC) pattern is followed throughout the book. The model manages the behavior and data of the portal domain, responds to requests for information about its state from the view, and responds to instructions to change its state from the controller. The view (like JSP, XHTML, JavaScript) renders the model into a form suitable for interaction, typically a user interface element; while the controller (such as actions, controllers) receives input and initiates a response by making calls on model objects.

In Liferay, there's a concept called a plugin, which is a WAR file that can be hot-deployed into the portal at runtime. Plugins can be categorized as portlets, themes, layout templates, hooks, and webs. These plugins can be developed using the Plugins SDK. Prior to Liferay 6, there used to be an ext environment, where the developer could customize the core portal module. Since Liferay 6, it has been replaced by the Ext plugins approach.

Service-Builder is a Liferay tool to generate persistence and service-layer code, by reading an XML file.

Of course, you're not required to write a lot of code yourself. You can use Service-Builder to generate a lot of the code for building the models and services. Generally speaking, the Service-Builder is a tool built by Liferay to automate the creation of interfaces and classes that are used by a given portal or portlet. The Service-Builder is used to build Java services that can be accessed in a variety of ways, including local access from Java code, as well as remote access using web services.

In general, the Service-Builder is a code generator. Using an XML descriptor, it generates:

• Java Beans

• SQL scripts for database tables creation

• Hibernate Configuration

• Spring Configuration

• Axis Web Services

• JSON JavaScript Interface

The Plugins SDK Environment is a simple environment for the development of Liferay plugins, such as ext, themes, layout templates, portlets, hooks, and webs (web applications). It is completely separated from the Liferay Portal core services by using external services only if required.

The portal supports six different types of plugins out-of-the-box. They are Portlets, Themes, Layout Templates, Webs, Hooks, and Ext:

• Portlets: Web applications that run in a portion of a web page

• Themes: Look-and-feel of pages

• Layout Templates: Ways of choosing how the portlets will be arranged on a page

• Hooks: Allow hooking into the portal core functionality

• Webs: Regular Java EE web modules designed to work with the portal such as ESB (Enterprise Service Bus), and SSO (Single Sign-On). Note that a web is a pure web application where a thin layer is added to provide checking for dependencies. A web also adds support for embedding hook definitions or Service Builder services within a plain old web application. And finally, you can deploy them using the auto-deploy mechanism the same way that you can with other plugins.

• Ext: ext environment as a plugin means you can use the extension environment as a plugin in the Plugins SDK environment.

As you can see, you can generate code for plugin Portlets, Webs, and Ext. Normally, you would have one project for each plugin, for example, theme, layout template, hook, ext, or web; you can have many portlets in one plugin project portlet. Hook plugins can be standalone, or they could be included with portlets and web. This means, in one plugin project portlet or web, you can have hooks and many portlets or a web as one WAR file. What are the advantages of aggregating many portlets into one WAR? We have shared database workspace with many portlets and can implement collaboration between each other.

Liferay IDE is used to provide best-of-breed Eclipse tooling for the Liferay Portal development platform for version 6 and greater. The availabilities of Liferay IDE cover, but are not limited to, the plugins SDK support, plugin projects support, project import and conversion, wizards, code assist such as portlet taglibs, customizable templates, and XML catalog (XSD) contributions.

Ext plugin

The Extension environment provides the capability to customize Liferay Portal completely. As it is an environment which extends Liferay Portal development environment, it has the name "Extension", (called "Ext"). With Ext, we could modify internal portlets which are also called by the out-of-the-box portlets. Moreover, we could override the JSP files of the portal and out-of-the-box portlets. This kind of customization is kept separate from the Liferay Portal source code. That is, the Liferay Portal source code does not have to be modified, and a clear upgrade path is available in the Ext.

Starting with version 6, Ext environment is available as a plugin called Ext plugin. As shown in the following diagram, custom code will override Liferay Portal source code in the Ext plugins only. In the deployment process, custom code is merged with Liferay Portal source code. That is, developers can override the Liferay Portal source code. Moreover, custom code and Liferay Portal source code will be constructed as a customized Liferay Portal first, and then the customized Liferay Portal will be deployed to an application server. In addition, both direct deploy (ant direct-deploy) and standard deploy (ant deploy) are available.

Hook plugin

Hooks are a feature to catch hold of the properties and JSP files into an instance of the portal, as if we were catching them with a hook. Hook plugins are more powerful plugins that complement portlets, themes, layout templates, and web modules. A hook plugin can, but does not have to, be combined with a portlet plugin or a web plugin. For instance, the portlet called so-portlet is a portlet plugin for social office with hooks; a hook plugin can simply provide translation or override a JSP page.

In general, hooks are a very helpful tool to customize the portal without touching the code of the portal, as shown in the following diagram. In addition, you could use hooks to provide patches for portal systems or social office products.

In general, there are several kinds of hook parameters:

• portal-properties (called portal properties hooks),

• language-properties (called language properties hooks),

• custom-jsp-dir (called custom JSPs hooks),

• custom-jsp-global (applying custom JSPs hooks globally or locally),

• indexer post processors (called indexer hook),

• service (called portal service hooks) including model listeners and service wrappers,

• servlet-filter and servlet-filter-mapping (called servlet-filter hooks),

• struts-action (called portal struts action hooks)

As you can see, JSPs hooks can set a custom-jsp-dir that will overwrite portal JSPs. You can also add<custom-jsp-global>false</custom-jsp-global> (default to true) so that JSPs hooks will not apply globally but only to the current scope. Each site (or organization) can choose to have that hook apply just for that site (or organization).

In addition, Liferay allows portal JSPs to be overloaded by theme templates this pattern will require that within the theme's templates folder, the complete path to the original JSP be maintained with the file extension replaced to match that of the theme's chosen template language.

Portlet, layout template, and web plugins

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

How does it work? As shown in the following diagram, the Plugins SDK provides an environment for developers to build portlets and webs. Later, it uses the Ant Target Deploy or Maven to form a WAR file and copy it to the Deploy directory. Then, Liferay Portal together with the application server will detect any WAR files in the Deploy (auto deploy, hot deploy, or sandbox deploy) folder, and automatically extract the WAR files into the application server deployment folder. Note that the portal is able to recognize the type of the plugin and enhance it appropriately before hot-deploying it. For example, for portlets it will modify web.xml by adding required listeners and filters.

During customization, you could use the Service-Builder to generate models and services in portlets and/or web plugins. In general, the Service-Builder is a code generator using an XML descriptor. For a given service.xml XML file, it will generate SQL for creating tables, Java Beans, Hibernate configuration, Spring configuration, Axis Web Service, and JSON JavaScript Interface. Of course, you can add hooks in portlets and/or webs plugins.

Theme plugin

A theme specifies the styles of all major global portlets and content; therefore, it controls the way the portal will look. In general, a theme uses CSS, images, JavaScript, and Velocity (or FreeMarker) templates to control the whole look-and-feel of the pages generated by the portal.

As shown in the following diagram, the theme plugin can use default themes as a basis, building differences on top.

Development strategies

As mentioned earlier, there are at least three development environments: portal core source code, Ext plugin, and normal plugins. Thus, you may ask: Which kind of development environment is suitable for our requirements? When should we use the Ext plugin? And when should we use other plugins, or even Liferay Portal source code? Let's take a deep look at the development strategies.

As shown in the following diagram, Liferay Portal is extensible on at least three levels, for example the Plugins SDK Environment (Level I), Ext plugin (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 versions. Thus we need to choose the appropriate level for the requirements at hand ; one which allows for the easiest future maintainability.

Level I development

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

In addition, portlets developed in the Plugins SDK can only import classes from the portal API (Portal-Service), not Portal-Impl. This means, portlet development in the Plugins SDK does not touch portal properties, language properties, core services, and JSP files related to Portal-Impl. Fortunately, hooks provide the capability to access portal properties, language properties, struts actions, core services related to Portal-Impl, and custom JSP files.

Level II development

In Level II, we can manage configuration files, custom source code, custom JSP files, and modified JSP files related to the Portal-Impl. This means that the, Ext plugin provides different sublevels (for example, configuration files, custom source code, custom JSP files, and modified JSP files) of extensibility.

Among the configuration files, portal-ext.properties has the main configuration options: layouts, deployment, themes, Hibernate, cache, instance settings, users, groups, language, session, auth, integration, and events. Meanwhile, the system-ext.properties file is a 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 need to be configured through the portal.properties file. Examples are authentication chain, upgrade and verification processes, deployment processes, database access and caching, user fields' generation and validation, session events, permissions, and model listeners.

For custom source code, we can use Spring-based dependency injection mechanisms configured in the ext-spring.xml file as follows:

1. 1. Add the Servlet extended in the web.xml file.

2. 2. Add the Struts action extended in the struts-config.xml file.

3. 3. Moreover, create portlets that access Portal-Impl, or events extending its models and services.

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.

Note

Without a doubt, it is easier to develop portlets in Ext plugin, where you can easily access and use all of the Portal APIs, taglibs, JSP files, and almost everything else. This isn't the case with the other plugins.

Starting with version 6, the Extension environment becomes the Ext plugin. Golden rule: support for Service-Builder in Ext plugins will be deprecated in future versions. Ext plugins are designed to override the portal's core code in ways that can't be done with hooks, layout templates, portlets, or themes. Ext plugins aren't meant to contain new custom services. Thus any 5.x service.xml in Ext environment should be migrated into a portlet plugin.

Level III development

In Level III, we can modify the Liferay Portal source code. This approach can only be used for sponsored development or providing patches for bug fixes, new features/improvements, and portal core contribution development. This means, you can develop specific features for specific projects first and then contribute back to Liferay Portal source code, or provide patches to override Portal-Impl, Util-Java, Util-Taglib and Util-Bridges partially.

In brief, if your requirements are related to customize and/or extend Portal-Impl (for example, UI changing, LDAP import algorithms, document and media library lock mechanism, forms for user registration or organization creation, integration, modifying the out of the box portlets, and so on.), you should use Ext plugin. Otherwise, it is better to use other Plugins. Note that with hooks, you can hook up portal properties, language properties, core services, and Struts actions related to Portal-Impl.

Keep in mind that Ext plugin is designed to override the portal's core code in ways that can't be done with hooks, layout templates, portlets, or themes; and Ext plugin shouldn't contain any custom services.