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.
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 1. A - HotDeals portlet on the Welcome page; B - Transaction portlet on the Transaction page, before user clicks any links
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.
Figure 2. Transaction portlet after user clicks a HotDeals link
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.
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:
- First, import
engine.tldfile into the portlet application directory:WebContent/WEB-INF/tld.For WebSphere Portal version 4.2.1, the
engine.tldis in directorywp_root/app/wps.ear/wps.war/WEB-INF/tld(wherewp_rootis the WebSphere Portal installation directory; for example:C:/WebSphere/PortalServeris the name for our installation).For version 5.0.2,
engine.tldis in directorywp_root/shared/app/WEB-INF/tld. - 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/>
- 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>
- Finally, enable the receiving portlet, Transaction, to get the id of the special offering, sent from the HotDeals portlet (See
TransactionPortlet.javain 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); }
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:
- Unzip
p2p_portal.zipto getP2PSample1_v421.warorP2PSample1_v502.war. You see there are two portlets in the war file:HotDealsportlet andTransactionportlet. - Install
P2PSample1_v421.warorP2PSample1_v502.warin WeSphere Portal. - 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.
- Add the HotDeals portlet to the Welcome page, and add the Transaction portlet to the Transaction page.
- 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.
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.
Figure3. A- QuickSearch portlet; B-SearchResult portlet
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.
- Similar to the previous sample, you import the
engine.tldtag library into the portlet application--P2PSample2, in this case. Include it in the jsp file (seeQuickSearchPortletView.jspin 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>
- 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") %>;"; }
- 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>
- 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); }
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:
- Unzip
p2p_portal.zipto getP2PSample2_v421.warorP2PSample2_v502.war. There are two portlets in the war file: QuickSearch portlet and SearchResult portlet. - Install
P2PSample2_v421.warorP2PSample2_v502.warin WebSphere Portal. - Create a Welcome page, or use the same one you created for the first sample.
- Create a Search Result page in P2PSample.
For WebSphere Portal V5.0.2, create a custom unique name
P2PSample.SearchResultfor page Search Result. - Add the QuickSearch portlet to the Welcome page, and add the SearchResult portlet to the Search Result page.
- 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.
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.
| Name | Size | Download method |
|---|---|---|
| p2p_portal.zip | 47KB | FTP |
Information about download methods
-
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.
Comments (Undergoing maintenance)







