EXT PlugIn

EXT PlugIn

Ext plugins provide the most advanced method of extending Liferay. This comes with some tradeoffs in complexity, and so Ext plugins are designed to be used only in special scenarios in which all other plugin types cannot meet the needs of the project.

Before deciding to use an Ext plugin it's important to understand the costs of using such a powerful tool. The important one is the cost in terms of maintenance. Because Ext plugins allow using internal APIs or even overwriting files provided in the Liferay core, it's necessary to review all the changes done when updating to a new version of Liferay (even if it's a maintenance version or a service pack). Also, unlike the other types of plugins, Ext plugins require the server to be restarted after deployment, as well as requiring additional steps when deploying or redeploying to production systems.

The main use cases in which an Ext plugin may be needed are:

·     Customizing portal.properties that are not supported by Hook Plugins

·     Customizing Struts Actions

·     Providing custom implementations for any of the Liferay beans declared in Liferay's Spring files (use service wrappers from a hook instead if possible)

·     Adding JSPs that are referenced from portal properties that can only be changed from an ext plugin (be sure to check if the property can be modified from a hook plugin before doing this)

·     Direct overwriting of a class (not recommended unless it's strictly necessary)

Creating an EXT plugin..

The most significant directories in this structure are the ones inside the docroot/WEB-INF directory. In particular you should be familiar with the following directories:

-    ext-impl/src: Contains the portal-ext.properties configuration file, custom implementation classes, and in advanced scenarios, classes that override core classes within portal-impl.jar.

-   ext-lib/global: Place here any libraries that should be copied to the global classloader of the application server upon deployment of the ext plugin.

-    ext-lib/portal: Place here any libraries that should be copied inside Liferay's main application. Usually these libraries are needed because they are invoked from the classes added within ext-impl/src.

-    ext-service/src: Place here any classes that should be available to other plugins. When using Service Builder

, it will put the interfaces of each service here. Also in advanced scenarios, this directory will contain classes that overwrite the classes of portal-service.jar.

-    ext-web/docroot: Contains configuration files for the web application, including WEB-INF/struts-config-ext.xml which will allow customizing Liferay's own core struts actions. You can also place any JSPs needed by your customizations here.

-    Other: ext-util-bridges, ext-util-java and ext-util-taglib are only needed in advanced scenarios in which you need to customize the classes of three libraries provided with Liferay: util-bridges.jar, util-java.jar and util-taglib.jar respectively. In most scenarios you can just ignore these directories.

By default, several files are added to the plugin. Here are the most significant ones:

Inside docroot/WEB-INF/ext-impl/src:

-        portal-ext.properties: This file can be used to overwrite any configuration property of Liferay, even those that cannot be overridden by a hook plugin (which is always preferred when possible). Note that if this file is included it will be read instead of any other portal-ext.properties in the application server. Because of that you may need to copy into it the properties related to the database connection, file system patches, etc.

Inside docroot/WEB-INF/ext-web/docroot/WEB-INF:

 -       portlet-ext.xml: Can be used to overwrite the definition of a Liferay portlet. In order to do this, copy the complete definition of the desired portlet from portlet-custom.xml within Liferay's source code and then apply the necessary changes.

-        liferay-portlet-ext.xml: Similar to the file above, but for the additional definition elements that are specific to Liferay. In order to override it, copy the complete definition of the desired portlet from liferay-portlet.xml within Liferay's source code and then apply the necessary changes.

-        struts-config-ext.xml and tiles-defs-ext.xml: Can be used to customize the struts actions used by Liferay's core portlets.

Developing an EXT plugin..

Developing an Ext plugin is slightly different than working with other plugin types. The main reason for the difference is that an Ext plugin when deployed will make changes to the Liferay web application itself, instead of staying as a separate

component that can be removed at any time. It's important to remember that once an Ext plugin has been deployed, some of its files are copied inside the Liferay installation, so the only way to remove its changes is to redeploy an unmodified Liferay application again.

Conclusion:

Ext plugins are a very powerful way of extending Liferay. There are no limits in what can be customized using them and for that reason they have to be used carefully. If you find yourself using an Ext plugin, verify if all or part of the desired functionality can be implemented through portlets, hooks or web plugins instead.

If you really need to use an Ext plugin make it as small as possible and implement.

Tip: after creating an Ext plugin, remove all of the files added by default that are not necessary for the extension. This is important because Liferay keeps track of the files deployed by each Ext plugin and it won't allow deploying two Ext plugins if they override the same file to avoid collisions. By removing any files not really necessary from an ext plugin it will be easier to use along with other Ext plugins.