How GroupSpace Uses IPC to Create Interportlet Links

by Charles Coates
10/18/2006

Abstract

Interportlet Communication (IPC) is a very powerful framework that is part of WebLogic Portal. It allows developers to create portlets that react to various events triggered in a portal application. This article looks at how IPC can be used to create an application framework that allows for the simple generation of HTML links in one portlet that, when clicked, trigger actions in a different portlet. I will focus specifically on a feature of the GroupSpace application that is part of BEA WebLogic Portal 9.2. The portlets in GroupSpace allow users to manage various types of collaboration content. Within these portlets, URL links that represent this content are often displayed on the portlet JSP pages. These links, via IPC, activate specific actions in the appropriate portlets based on the type of content they represent. This feature enhances the user experience and increases the overall cohesiveness of the portal application.

While this article focuses on the GroupSpace implementation of this feature, the code samples shown can be used as a guide to creating a similar framework in other custom portal applications that utilize pageflow-based portlets.

This article assumes a basic understanding of the following WebLogic Portal and Java technologies:

Feature Description

GroupSpace is a collaborative application that consists of several portlets that allow users to manage various content types. These content types include collaborative elements such as Issues, Discussion Topics, GroupNotes (rich text documents), and external documents. In many of these portlets, there is often a need to display a link to one of these content items. One example of this need is in the Search portlet. Search results contain a heterogeneous list of many different content types. Each item in the list is displayed as an HTML link. When these links are clicked, the application must activate the appropriate portlet (for example, an Issue link must activate the Issues portlet) and fire a pageflow action to display the detailed information about the specific content item.

Since these links will be placed on many portlet JSP pages, the URL generation for the links is simplified. This is best accomplished using a custom JSP tag.

Finally, the framework provides support for adding new portlets that respond to new content types. This involves no additional coding to the underlying framework components.

Implementation

The ultimate goal for this framework is to make it very simple for a JSP page developer to create a URL link that represents a GroupSpace content item (that is, an Issue, GroupNote, and so on). When a user clicks on this link, the application should automatically activate the portlet designed to display information about that content type. For example, a URL link that represents a GroupSpace Issue should activate the Issues portlet, and a URL link that represents a GroupNote should activate the GroupNotes portlet. The complexity lies in creating a way to generate the href of the HTML anchor tag that will execute the logic necessary to determine the appropriate portlet, and then display the detailed information about the specific content item.

The basic approach is to start with a portal PostbackURL. I will add some parameters to this URL to indicate that a GroupSpace link has been clicked. I will also add parameters that uniquely identify what content item was clicked (a contentId) and what the content type is (such as Issue or GroupNote). When a request is submitted to this URL, the lifecycle methods that are defined in the portlet backing files will get executed. You can add some logic to the backing file that will determine which portlet should handle the request. You can then make use of IPC to fire a custom event that the portlets are listening for. The portlet that was identified to handle the content type will react to the event by executing a designated pageflow action. This action will ultimately display the details of the specific content item based on its unique id.

Several components are involved in the implementation of this framework. The following sections describe each component and include code samples with detailed explanations. The code samples have been taken from the GroupSpace application.

Backing file

The first step is to create a portlet backing file that all portlets participating in the framework must use. This is the backing file that will get executed when a user clicks on a content link. The handlePostbackData() method will be used to determine if a link has been clicked and will prepare the event for the correct portlet to handle. Here is a sample of this code:

1  public boolean handlePostbackData(HttpServletRequest req, 

2                                    HttpServletResponse res) {

3

4    // Determine if a GroupSpace content link was clicked.

5    String linkClicked = req.getParameter("gsLink_linkClicked");

6    if (linkClicked != null && linkClicked.equals("true")) {

7

8      // Determine if the event was already prepared by a 

9      // previously run portlet backing file.

10     String eventPrepared = 

11       (String) req.getAttribute("gsLink_eventPrepared");

12     if (eventPrepared == null) {

13

14       // Find all portlets that can handle the type.

15       String type = req.getParameter("gsLink_contentType");

16       if (type != null) {

17         String[] values = a;

18         MetaData[] metaData = 

19           {new MetaData("gsLink_contentType", values)};

20

21         DesktopBackingContext dback = 

22           DesktopBackingContext.getDesktopBackingContext(req);

23         PortletBackingContext[] pback = 

24           dback.getPortletBackingContextsByMeta(metaData, 0);

25         if (pback != null && pback.length > 0) {

26

27           String instanceId = pback[0].getInstanceId();

28

29           // Determine which portlet is the best to handle the 

30           // displaying of the content details based on the

31           // current portlet and current page.

32           String curPortletId = 

33             req.getParameter("gsLink_currentPortletId");

34           String curPageId = 

35             req.getParameter("gsLink_currentPageId");

37           if (curPageId != null) {

39             for (int i = 0; i < pback.length; i++) {

40               PageBackingContext pContext = 

41                 pback[i].getPageBackingContext();

42               if(curPageId.equals(pContext.getInstanceId())) {

43                 instanceId = pback[i].getInstanceId();

44               }

45             }

46           }

47

48           if (curPortletId != null) {

49             for (int i = 0; i < pback.length; i++) {

50               if (curPortletId.equals(pback[i].getInstanceId())) {

51                 instanceId = pback[i].getInstanceId();

52               }

53             }

54           }

55

56           // Set the target portlet id (the one that will 

57           // display the details) as a req attribute.

58           req.setAttribute("gsLink_targetPortletId", 

59             instanceId);

60         }

61       }

62       req.setAttribute("gsLink_eventPrepared", "true");

63       req.setAttribute("gsLink_detailsEventHandled", "false");

64       PortletBackingContext myBacking = 

65         PortletBackingContext.getPortletBackingContext(req);

66       myBacking.fireCustomEvent("linkClickedEvent", "payload");

67     }

68   }

69

70   return false;

71 }

Line 5 determines if a link has been clicked. This action can be verified by checking for a known request parameter. Further on in this article, you will see how specific request parameters will be set when a link is clicked. If a link has been clicked, next you must determine if a previously run backing file has already prepared the event (line 10). Again, this can be verified by checking for a known request parameter.

Pages: 1, 2, 3, 4

Next Page ยป