Introduction

WebSphere Portal has built-in features, such as portlet messaging and cooperative portlets (formerly known as Click-to-Action portlets in V4.2), for portlet-to-portlet communication on the same page, but it does not yet have a well-known feature for page-to-page communication. In real WebSphere Portal applications, portlets sometimes need to communicate from page-to-page.

These two scenarios are likely page-to-page communication requirements:

• A simple link from a portlet on one page carries static information to a portlet on another page. The portlet on the second page uses the data in some meaningful way.
• A user enters information on a portlet on one page, and then clicks a link (or button). That link carries the user data to a portlet on a second page, and it uses the data it receives from the first portlet.

In this article, you see specific instances of these two scenarios, and you can download the accompanying sample portlets for each of this cases.

The following products were used to develop and test the samples:

• IBM WebSphere Portal V4.2.1 and V5.0.2
• IBM WebSphere Studio Application Developer V5.1
• IBM Portal Toolkit, Version 5.0.2 for Multiplatforms
• Microsoft® Internet Explorer V6.0
• Netscape v7.1

While future releases of WebSphere Portal could extend the current cooperative portlet support to exchange data between portlets on separate pages, the solution provided in this article should still work.

Back to top

Scenario 1: Static links with pre-defined data

Suppose you are building a WebSphere Portal application for a company. The company wants to add to most of its pages a HotDeals portlet, which lists current special offers by the company and its partners. The HotDeals portlet can call either a Web service or database to dynamically display the special offers for the day. When a user clicks a link in the HotDeals portlet, the Transaction portlet on the Transaction page, to process the deal.

Figure 1 A shows the HotDeals portlet on the Welcome page; Figure 1 B shows the Transaction portlet on the Transaction page before a user clicks any links on the HotDeals portlet; that is, the user simply clicks the Transaction tab.

Figure 2 shows the Transaction portlet on the Transaction page after a user clicks one of the links in the HotDeals portlet on the Welcome page.

This scenario requires page-to-page communication between portlets. When a user clicks a link in the HotDeals portlet on the Welcome page (or other pages), the portlet passes the id of the special offering to the Transaction portlet on the Transaction page.

Implementing P2PSample1

The solution we implemented for this scenario uses URL (Uniform Resource Locator) parameters, and the engine.tld tag library (engine.tld is normally used to create themes and skins). This solution, P2PSample1PortletView.jsp, is included in the download file.

To implement the jsp page for the HotDeals portlet:

1. First, import engine.tld file into the portlet application directory: WebContent/WEB-INF/tld.

   For WebSphere Portal version 4.2.1, the engine.tld is in directory wp_root/app/wps.ear/wps.war/WEB-INF/tld (where wp_root is the WebSphere Portal installation directory; for example: C:/WebSphere/PortalServer is the name for our installation).

   For version 5.0.2, engine.tld is in directory wp_root/shared/app/WEB-INF/tld.

2. Next, define the tag librarie in the jsp page of HotDeals portlet (see P2PSample1PortletView.jsp):

   <%@ page session="false" contentType="text/html" import="java.util.*, p2psample.portlet.hotdeals.*, p2pSample1.util.*"%> <%@ taglib uri="/WEB-INF/tld/portlet.tld" prefix="portletAPI" %> <%@ taglib uri="/WEB-INF/tld/engine.tld" prefix="wps" %> <portletAPI:init/>

   
   
3. Define the link to the Transaction portlet on the Transaction page. In WebSphere Portal version 4.2.1, the <wps:urlSelect> tag can be used to generate a link pointing to a different page. We appended the hotDealId as a url parameter.

   <wps:urlSelect placeName="P2PSample" pageName="Transaction"> <a href="<%= wpsSelectURL + response.encodeURL("?hotDealId=" + hotDeals[i].getDealId()) %>"> <%= hotDeals[i].getDealName() %> </a> </wps:urlSelect>

   
   

   However, the <wps:urlSelect> tag has been replaced by <wps:urlGeneration> tag in WebSphere Portal V5. Therefore, the code for V5 is:

   <wps:urlGeneration contentNode="P2PSample.Transaction" portletWindowState="Normal"> <wps:urlParam name="hotDealId" value="<%= hotDeals[i].getDealId()%>" /> <a href="<% wpsURL.write(out); %>"> <%= hotDeals[i].getDealName() %> </a> </wps:urlGeneration>

   
   
4. Finally, enable the receiving portlet, Transaction, to get the id of the special offering, sent from the HotDeals portlet (See TransactionPortlet.java in the download).

   public void doView(PortletRequest request, PortletResponse response) throws PortletException, IOException { // Get the id of the deal sent from the HotDeals portlet String hotDealId = request.getParameter("hotDealId"); // Make a view mode bean TransactionPortletViewBean viewBean = new TransactionPortletViewBean(hotDealId); request.setAttribute(VIEW_BEAN, viewBean); // Invoke the JSP to render getPortletConfig().getContext().include(VIEW_JSP, request, response); }

   
   

Deploying the P2PSample1

Using the files in the download, you can deploy this sample application. The file names of this first sample portlet application are:

• For WebSphere Portal V4.2.1: P2PSample1_v421.war
• For WebSphere Portal V5.0.2: P2PSample1_v502.war

Both files are included in the download zip file.

To deploy the portlets:

1. Unzip p2p_portal.zip to get P2PSample1_v421.war or P2PSample1_v502.war. You see there are two portlets in the war file: HotDeals portlet and Transaction portlet.
2. Install P2PSample1_v421.war or P2PSample1_v502.war in WeSphere Portal.
3. Create the pages to hold the portlets.

   For WebSphere Portal V4.2.1, create a place called P2Psample. Then, create two pages, Welcome and Transaction, in the P2PSample place.

   For WebSphere Portal V5.0.2, create a label P2PSample under My Portal. Then, create two pages, Welcome and Transaction, under the P2PSample label. Finally, create a custom unique name P2PSample.Transaction for the Transaction page.

4. Add the HotDeals portlet to the Welcome page, and add the Transaction portlet to the Transaction page.
5. Run and test the application.

This solution does not require a portlet session, so you can use it for a public portal with anonymous users.

Back to top

Scenario 2: Linking with user input data

Now, suppose the company wants to add a QuickSearch portlet to most of the pages in its portal so that users can easily search on the company Web site. When a user enters search text and clicks the Search link, the SearchResult portlet displays the search result.

Figure 3 A shows the QuickSearch portlet, and Figure 3 B shows the SearchResult portlet. To simplify this scenario, we did not implement the search function of the SearchResult portlet; instead, SearchResult simply displays the user input data.

Implementing P2Psample2

This scenario solution needs to send user input text from the QuickSearch portlet on the Welcome page (or other pages) to the SearchResult portlet on the Search Result page. We used a cookie to carry this user input data.

1. Similar to the previous sample, you import the engine.tld tag library into the portlet application--P2PSample2, in this case. Include it in the jsp file (see QuickSearchPortletView.jsp in the download):

   <%@ page session="false" contentType="text/html" import="java.util.*, com.ibm.wps.services.config.Config, p2psample2.portlet.quicksearch.*"%> <%@ taglib uri="/WEB-INF/tld/portlet.tld" prefix="portletAPI" %> <%@ taglib uri="/WEB-INF/tld/engine.tld" prefix="wps" %> <portletAPI:init/> </SCRIPT>

   
   
2. Create a Javascript function to set up the cookie. Set up the expiration time of the cookie to 5 minutes. In a portlet application, you encode the Javascript function name.

   <SCRIPT LANGUAGE="JavaScript"> function <%= portletResponse.encodeNamespace("QuickSearch_Set_Cookie") %>(cookie_name, userInputData) { var expTime = 5; var exp = new Date(); exp.setTime(exp.getTime() + (expTime*60*1000) ); document.cookie=cookie_name+"=" + userInputData + "; expires=" + exp.toGMTString() + "; path=/wps; domain=<%= Config.getParameters().getString("host.name") %>;"; }

   
   
3. Call the Javascript to set up the cookie when a user enters search text.

   For WebSphere Portal V4.2.1:

   <form name="<%= portletResponse.encodeNamespace("SearchForm") %>"> Enter search text:<br/> <INPUT class="wpsEditField" name="<%= portletResponse.encodeNamespace("quickSearchText") %>" type="text" onChange="<%=portletResponse.encodeNamespace("QuickSearch_Set_Cookie")%> ('P2PSampleSearchTextCookie', this.value)"/> <wps:urlSelect placeName="P2PSample" pageName="Search Result"> <a href="<%= wpsSelectURL %>"> Search </a> </wps:urlSelect> </form>

   
   

   The <wps:urlSelect> tag has been replaced by <wps:urlGeneration> tag in WebSphere Portal V5; the code for V5 is:

   <form name="<%= portletResponse.encodeNamespace("SearchForm") %>"> Enter search text:<br/> <INPUT class="wpsEditField" name="<%= portletResponse.encodeNamespace("quickSearchText") %>" type="text" onChange="<%=portletResponse.encodeNamespace("QuickSearch_Set_Cookie")%> ('P2PSampleSearchTextCookie', this.value)"/> <wps:urlGeneration contentNode="P2PSample.SearchResult" portletWindowState="Normal"> <a href="<% wpsURL.write(out); %>"> Search </a> </wps:urlGeneration></form>

   
   
4. Finally, the ResultSearch portlet can retrieve the user input data from cookie and do the search to display the search results.

   public void doView(PortletRequest request, PortletResponse response) throws PortletException, IOException { SearchResultPortletViewBean viewBean = new SearchResultPortletViewBean(); Cookie[] cookies = request.getCookies(); StringBuffer buffer = new StringBuffer(); if ( cookies != null ) { for (int i = 0; i < cookies.length; i++ ) { Cookie cookie = cookies[i]; if ( cookie.getName().startsWith(COOKIE_NAME)) { viewBean.setSearchText(cookie.getValue()); } } } request.setAttribute(VIEW_BEAN, viewBean); // Invoke the JSP to render getPortletConfig().getContext().include(VIEW_JSP, request, response); }

   
   

Deploying P2PSample2

The file names of this portlet application in the download are:

• For WebSphere Portal V4.2.1: P2PSample2_v421.war
• For WebSphere Portal V5.0.2: P2PSample2_v502.war

To deploy the portlets:

1. Unzip p2p_portal.zip to get P2PSample2_v421.war or P2PSample2_v502.war. There are two portlets in the war file: QuickSearch portlet and SearchResult portlet.
2. Install P2PSample2_v421.war or P2PSample2_v502.war in WebSphere Portal.
3. Create a Welcome page, or use the same one you created for the first sample.
4. Create a Search Result page in P2PSample. For WebSphere Portal V5.0.2, create a custom unique name P2PSample.SearchResult for page Search Result.
5. Add the QuickSearch portlet to the Welcome page, and add the SearchResult portlet to the Search Result page.
6. Run and test the application.

Similar to sample 1, this solution does not require a portlet session, so you can use it on a public portal with anonymous users.

Back to top

Conclusion

Page-to-page communication between portlets in WebSphere Portal can be implemented using URL parameters or cookies. You can use URL parameters communication which does not carry user input data and cookies if the portlets need to transfer user input data. It is not a good design to use lots of page-to-page communication in a WebSphere Portal application. Page-to-page communication is suitable for portlets that are on many pages and do not have much user input data.

Back to top

Download

Name	Size	Download method
p2p_portal.zip	47KB	FTP|HTTP

Information about download methods

Resources

• WebSphere Portal product documentation is the primary resource for installation, configuration, and development information.
  
  
• See the WebSphere Portal zone for additional articles, samples, tutorials, and references for developing portals.
  
  
• Using Click-to-Action to provide user-controlled integration of portlets provides an overview of the original cooperative portlet support in WebSphere Portal V4, which provided the foundation for passing data between portlets on a page.
  
  
• Using cooperative portlets in WebSphere Portal V5 provides an overview of the extensions made to Click-to-Action between versions 4 and 5, including a persistent connection, called a wire, between portlets. Property transfers can occur as a side-effect of user interactions with a source portlet, so that users no longer have to explicitly pick an action on the target from a menu.
  
  
• Implementing portlet messaging using WebSphere Studio Application Developer V5 and the Portal Toolkit V5 shows how to develop a portlet application, using WebSphere tooling, and how to enable one portlet to send a message to a second portlet (on the same page).
  
  
• Wiring Click-to-Action portlets for inter-portlet communication in WebSphere Portal V5 provides step-by-step instructions for enabling portlet-to-portlet communication, on the same page, using wiring, and with minimal code and configuration..
  
  
• Passing complex data types between cooperative portlets shows how you can pass a complex data type between portlets on the same page in WebSphere Portal V5.
  
  
• Portlet messaging with IBM WebSphere Host Access Transformation Services (HATS) describes how to use WebSphere Portal and the IBM Portal Toolkit with HATS business logic to create messaging between portlets on a Web page.
  
  

About the authors

Hongqing Song has been a WebSphere consultant since 2000. He provides WebSphere consulting services across the nation. He works in IBM Austin in eServer Solutions Enablement.

Richard Scott is an Architect and Technical Lead in IBM Dallas, eServer Solutions Enablement.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Scenario 1: Static links with pre-defined data
• Scenario 2: Linking with user input data
• Conclusion
• Download
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into WebSphere on developerWorks

DB2 pureScale

See how true transparent scaling architecture can be achieved on distributed platforms

Special offers