How GroupSpace Uses IPC to Create Interportlet Links
Pages: 1, 2, 3, 4

The next step is to prepare the event. In line 15 you determine what type of content was clicked by checking a request parameter. The next several lines of the code are used to determine which portlet should handle the event for that content type. This is done using portlet metadata. Setting portlet metadata is explained in more detail in the Portlet configuration section on the next page.

A couple more pieces of information are obtained via request parameters in lines 32 to 35. The current portlet id indicates in which portlet the clicked link was rendered. The current page id indicates the id of the page on which the current portlet resides. These two pieces of information are important in two special cases:

  • If the current portlet is capable of handling the content type, then it will be the portlet designated to handle the event.
  • If a portlet capable of handling the content type exists on the same page as the current portlet, then it will be the portlet designated to handle the event.

These special cases help reduce the amount of "jumping around" the user experiences when navigating these links.

Lines 37 to 54 determine the instance id of the portlet that is most appropriate to handle the event for the content type. That id is added as a request attribute in line 58.

Finally, a couple more request attributes are set to indicate that the event has been prepared and not yet handled. A custom event is then fired. This is the first of two IPC events. In the Portlet configuration section, you will see how these events are configured.

Event handler

The next step is to add a custom event handler method to the backing file. This method will be called by the IPC framework. It will be the action to an event that is defined for the various portlets that will be participating in this framework. This will become more clear when you look at the portlet configuration that is required as part of this implementation. Here is a sample of this code:

1  public void gsLink_evalLinkHandler(HttpServletRequest req, 
2                                     HttpServletResponse res, 
3                                     Event event) {
5    String targetPortletId = 
6        (String) req.getAttribute("gsLink_targetPortletId");
7    PortletBackingContext myBacking = 
8        PortletBackingContext.getPortletBackingContext(req);
9    String myId = myBacking.getInstanceId();
11   // Only react to this event if my portlet id matches the 
12   // one set in the request.
13   if (targetPortletId != null && targetPortletId.equals(myId)) {
15     MetaData meta = myBacking.getMetaData("gsLink_idAttrName");
16     if (meta != null && meta.getContents() != null 
17         && meta.getContents().length > 0) {
19       // Determine what the content id attribute name should 
20       // be as specified in the portlet metadata.
21       // Then set it in the request.
22       String idAttrName = meta.getContents()[0];
23       req.setAttribute(idAttrName, 
24           req.getParameter("gsLink_contentId"));
26       // Flag the request so that the resulting portal page 
27       // knows that the details event was handled.
28       req.setAttribute("gsLink_detailsEventHandled", "true");
30       // Fire off the show details event.  This event is only 
31       // being listened to by itself.
32       myBacking.fireCustomEvent("showDetailsEvent", "payload");
33     }
34   }
35 }

The first step in this method is to determine if the current portlet is the one that should handle the event (lines 5 to 13). This is accomplished by comparing the current portlet instance id with the targetPortletId that was set in the request during the event preparation (see the code sample, line 58 , in the Backing file section). If it is, you must further prepare the request so that the pageflow action that is ultimately executed can determine which content item was originally clicked. In line 22, the name of the id attribute is obtained from the portlet metadata. This metadata is further explained in the next section, Portlet configuration. The content id is then taken from the request parameter and set as a request attribute keyed by that id attribute name.

In line 28, you set the request attribute "gsLink_detailsEventHandled" to "true" to indicate that a portlet has responded to the event. By flagging the request like this, you can determine on the JSP page if a portlet has properly handled the click event. If no portlet was found to handle the event for a given content type, you can communicate this information to the user.

Another custom event is then fired at line 32. This is the second of the two IPC events that get fired in this implementation.

Pages: 1, 2, 3, 4

Next Page ยป