Portlet Modes

The mode indicates the function that the portlet is currently performing. A portlet’s current mode is passed to it by the portlet container. Based on the mode, the portlet can choose to generate different contents. In processAction() method, the portlet can change the mode programmatically.

 

Portlets can be in 3 modes:

1. View (represented by PortletMode.VIEW) – usually portlets represent their current state
2. Edit (PortletMode.EDIT) – Options to edit data are presented here
3. Help (PortletMode.HELP) – Generic or context sensitive information about the portlet provided here.

 

The portlet modes that a user has access to can be restricted by his authentication credentials (e.g. guest can only read and access help).

 

Custom portlet modes are also supported. These custom modes can be portal managed (portal will manage custom modes for the portlet) or portlet managed (portlet manages its mode in its own code. Portal not aware of portlet’s modes).

 

In portlet.xml, the modes that the portlet supports are indicated as follows:

 

<portlet>

  …

  <supports>

    <mime-type>text/html</mime-type>

    <portlet-mode>view</portlet-mode>

    <portlet-mode>edit</portlet-mode>

    <portler-mode>help</portlet-mode>

  </supports>

</portlet>

 

Initialization parameters to a portlet can be specified as follows in portlet.xml:

 

<portlet>

  <init-param>

    <name>view-action</name>

    <value>test</value>

  </init-param>

  <init-param>

    <name>edit-action</name>

    <value>test2</value>

  </init-param>

  …

</portlet>

 

These initialization parameters can be accessed in the portlet using the PortletConfig.

      

Portlet lifecycle

The portal, during the course of managing a portlet, passes the portlet through the following stages

1. Init
2. Process Action
3. Render
4. Destroy

There is one method in the Portlet interface for these stages. Right before a stage change occurs (e.g. when the portal is about to destroy a portlet), the portal notifies the portlet by invoking the appropriate method (the destroy() method for e.g.) on the Portlet Interface.

 

These are the possible state transitions

Init -> Process Action <-> Render -> Destroy

 

1. Init – Porlet is loaded and instantiated either on portlet container start or upon receipt of request for the portlet. Following this, the init() method on the portlet will be invoked. Portlets usually initialize expensive resources (connections for e.g.) at this time
2. Process Action & Render - Requests raised by portlets can from
1. Action URL: request fires processAction() method on portlet on which the URL resides and render() method on all the portlets. The portlet, in its processAction() method, updates its model. The render() method generates a view that indicates the current state of the model.
2. Render URL: request only fires render() method on all the portlets.
3. Destroy – Portal’s notice that the portlet is to be removed. Typically, a portlet will release all resources and persist any yet-to-be-persisted state/model.

 

Strategies for development with Liferay

Following options can be adopted for developing Liferay based solutions

1. Plug-in SDK Environment (least [but sufficient in most cases,] flexibility and least migration effort): Liferay supports different types of plugins such as themes, layout templates, portlets, webs (which are web applications) and hooks. Liferay provides a Plug-in SDK to facilitate development of these plugins. One can extend by implementing the appropriate plug-in.

2. Extension Environment (Very good flexibility and can need extensive migration effort): This approach involves writing custom code that overrides Liferay code. Following approaches to overriding liferay code exist:

a. Modifying JSP files (of the porttal or the built in portlets)

b. Modifying configuration files (portal-ext.properties [layouts, themes, hibernate, cache, users, groups ets...], system-ext.properties [for java system properties used by liferay], ext-spring.xml [custom source code being spring dependency injected], web.xml [for servlet configuration], struts-config.xml [for struts related extension]

c. Custom classes (configures through portal.properties)

This approach does *not* include changing Liferay source code.

3. Modifying Liferay Source code: Pay Liferay, get their source code changed and contributed back to community.

Source: Liferay Portal System Development

Portlets in Liferay

There are 3 approaches to building portlets that can be deployed in liferay

1. JSR 168/286 Compliant Portlet - This is a standards compliant portlet and can hence be deployed not only in Liferay but in any portal server. The downside is it cannot use Liferay specific APIs.

2. Liferay plugin portlet - These portlets are liferay plugins. They may have a dependency on Liferay APIs (Portal kernel and Portal Service). Having dependencies on Liferay APIs restricts their portability to Liferay only.

3. Web application exposed as a portlet - One type of a Liferay plugin is a web applications (webs). So a simple web application can be exposed as a portlet in Liferay using the webs plugin.

Source: Liferay Portal System Development