Liferay: Understanding theme:defineObjects

In the previous post, we have gone through the implicit objects provided by <portlet:defineObjects/>. In the continuation, today we will go through the implicit objects provided by <theme:defineObjects />.

Similar to <portlet:defineObjects/>, <theme:defineObjects /> is also an empty tag without any attribute, and must be included after the mentioned directive. Lets see the objects:

1. ThemeDisplay themeDisplay - contains attributes such as groupId, company id, user id, if the user is logged in, etc..
2. Company company – Portal instance specific information
3. Account account – current user’s account object
4. User user – logged in user’s attributes
5. User realUser – in case of impersonation, gets the logged in user’s id
6. Contact contact – current user’s contact object
7. Layout layout – current page attributes
8. List<Layout> layouts
9. long plid - current portlet layout id
10. LayoutTypePortlet layoutTypePortlet – object having information about portlets on the current layout
11. long scopeGroupId – groupid of the current scope
12. PermissionChecker permissionChecker – attributes regarding surrent user’s permission
13. Locale locale – current user’s locale, determined by JVM
14. TimeZone timeZone – current user’s timezone, determined by JVM
15. Theme theme – attributes of current theme being rendered on the page
16. ColorScheme colorScheme – attributes of the current colour scheme of the current theme
17. PortletDisplay portletDisplay – attributes regarding name, ID, portlet mode etc.

That’s all for today. Thanks for reading and have a nice day.

Liferay: Understanding portlet:defineObjects

There is so much confusion about the implicit objects provided by <portlet:defineObjects/> tag on JSP as developers cannot see them easily. Experienced developers know what is available and they can use them freely. Here is a cheat sheet for the same.

<portlet:defineObjects/> is an empty tag without any attribute, and must be included after the mentioned directive.

JSR -286 (Portlet 2.0) have objects available from the following 13 objects, depending upon the origin of render, which lies in 3 categories:

1. Request Objects
1. RenderRequest – if the origin of request is from render phase
2. ActionRequest - if the origin of request is from action phase
3. ResourceRequest - if the origin of request is from ajax (serveResource)
4. EventRequest - if the origin of request is from event (processEvent)
2. Response Objects
1. RenderResponse - if the origin of request is from render phase
2. ActionResponse - if the origin of request is from action phase
3. ResourceResponse - if the origin of request is from ajax (serveResource)
4. EventResponse - if the origin of request is from event (processEvent)
3. Portlet Objects
1. PortletConfig
2. PortletSession
3. Map<String, Object> - contains list of all portletSessionAttributes
4. PortletPreferences
5. Map<String, String[]> - contains list of all portletPreferences

That’s all for today. Thanks for reading and have a nice day.

Liferay: A note of Liferay IPCs

Now as we have discussed about all 5 kinds of IPCs in Liferay, We should have some preference which one to use first.

Obviously Server Side IPC should be considered first, and then the client side implementations.

As per my understanding, following is the order of IPC mechanisms one should consider while implementing IPC.

1. IPC via Server Side Events (Read here)

2. IPC via Private Session Attributes (Read here)

3. IPC via Public Render Parameters (Read here)

4. Client Side IPC via Events/Ajax (Read here)

5. Client Side IPC via Cookies (Read here)

That’s all for today. Thanks for reading and have a nice day.

Liferay: IPC via Private Session Attributes

Every portlet WAR has a session associated with it. A portlet session is a java object. This session object can be used for sharing data between portlets and achieving IPC. So this article will explain IPC via portlet session.

To understand Portlet sessions, we have to understand session scope of the session object. There are two scopes – PORTLET_SCOPE and APPLICATION_SCOPE.

The data stored in the PortletSession of a portlet is not shared with any other portlets on the page, or anywhere else in the portal. This default behaviour is known as PORTLET_SCOPE. With the JSR-168(Portlet 1.0) portlet specification, concept of APPLICATION_SCOPE was introduced, and is available in its successor JSR-286(Portlet 2.0) which gives data access to all the portlets of the same WAR.

Let’s see the snippets:

Portlet 1: Setting Attributes:

PortletSession portletSession = renderRequest.getPortletSession();

// Application Scope
portletSession.setAttribute("appParam","I’m Sample App Scope Param Value", PortletSession.APPLICATION_SCOPE);
// Portlet Scope
portletSession.setAttribute("portletParam"," I’m Sample Portlet Scope Param Value ", PortletSession.PORTLET_SCOPE);

Portlet 2: Fetching Attributes:

PortletSession portletSession = renderRequest.getPortletSession();

// Application Scope
String appParam = (String) session.getAttribute("appParam", PortletSession.APPLICATION_SCOPE);
// Portlet Scope
String portletParam = (String) session.getAttribute("portletParam", PortletSession.PORTLET_SCOPE);

Portlet session attributes can be removed also, using the following:

PortletSession portletSession = renderRequest.getPortletSession();

portletSession .removeAttribute("appParam")
portletSession .removeAttribute("portletParam ", PortletSession.PORTLET_SCOPE);

Please note that both methods are interchangeable.

Liferay further provide feature for sharing portlet session attributes with portlet from other WARs. For achieving the same, we have to set <private-session-attributes> to false in liferay-portlet.xml.

That’s all for today. Thanks for reading and have a nice day. 

Liferay: Client Side IPC via Events/Ajax

Client Side IPC using Ajax is another way of achieving communicating between portlets from client size. This mechanism was introduced in JSR-286 (Portlet 2.0) specification and provides a very lightweight and decoupled mechanism to communicate portlets purely in the browser through a JavaScript events mechanism.

The API of this system is very simple and is based on two methods

Liferay.fire(eventName, data);

Liferay.on(eventName, function, [scope]);

Prerequisite for this includes - setting <requires-namespaced-parameters> to false, in liferay-portlet.xml file of the both the portlets, which makes allows to share data via Ajax call and adding both the portlets in the same page after deployment.

Let’s see some snippets:

Portlet 1: JS code for setting params

$(document).on('ready',function(){
 var param1 = "I'm a sample value of Param 1";
 var param2 = "I'm a sample value of Param 2";
 $.ajax({
  url:'',
  dataType: "json",
  data:{param1: param1, param2: param2},
  type: "get",
  success: function(data){
   Liferay.fire('setParamsViaAjax', {eventData: data});
   },
  complete: function(){
   alert('Success');
   },
  error: function(){
   alert(Some 'Error');
   }
 });
});

Portlet 2: JS code for fetching the Params

Liferay.on('setParamsViaAjax', function(event) {
 alert("Param 1: " + event.eventData.param1);
 alert("Param 2: " + event.eventData.param2);
}); 

That’s all for today. Thanks for reading and have a nice day.

Liferay: Client Side IPC via Cookies

I’m starting to write here again after long time. I was keeping busy while working on ReactJS and it’s integration with Liferay. However, I’m here continuing from where I left and will start about ReactJs and its integration with Liferay soon. 

In the previous two posts we’ve seen IPC via Public Render Parameter and Server Side Events. Today I’ll write about Client Side IPC at using Cookies. As IPC via Public Render Parameters and Server Side Events, this concept was also introduced in JSR 286.

Important point to note about Client Side IPC via Cookies is that we cannot have information stored/shared more than 4096 bytes in size, as this is the maximum size of a cookie allowed by browsers and maximum number of cookies allowed, varies browser to browser; which is, for example, 20 in case of IE and 600 in case of Safari Mobile. (You can read details here)

The scenario we’ll see here in snippet will be: creating the cookie in Portlet 1 and reading the same in portlet 2. I’m keeping name of the cookie ‘sampleIPCCookie’ for example.

Setting/Getting the cookie can be done by either of the method - server side (Java/JSP etc.) or client side (Javascript/JQuery etc.). Here I am writing example using of Javascript.

Let’s go and see the snippets.

Portlet 1: Setting the cookie 


Portlet 2: Fetching the cookie value in another portlet. 
Client Side IPC via cookies is not a best practice of IPC and should be considered as the last option for implementing IPC. If it is very necessary to implement IPC at client side, one should first consider Client Side Events (which we’ll see in the next post) before considering this mechanism.

That’s all for today. Thanks for reading and have a nice day.