Inter-portlet Communication

Inter-portlet Communication

Portlets are designed to be independent views of data. That said, creating portlets that share information with one another is possible. To pass information from one portlet to another, you use URL parameters. These parameters can be processed in two different places. You can use a backing file, or you can simply have the receiving JavaServer Pages (JSP) file know which parameter it's looking for. Using a backing file gives you the advantage of separating business logic from presentation logic. Figure 13.1 shows how inter-portlet communication works and illustrates the two options for processing parameters.

Figure 13.1. Inter-portlet communication with WebLogic Portal.

JSP Processing

To understand JSP processing, using an example is helpful. In the Wonderland Casino domain, it has been decided that the rules for a game shouldn't always be displayed. In fact, the rules for a particular game should be displayed only if a user wants to see them. In this chapter, you examine how to set this up for roulette; the concepts are the same for all the other games .

First, you need to identify the sender and receiver. The sender is the roulImage.jsp portlet, in which you need to add a link to give users the option to display rules. The receiver is the roulette.jsp file used to display the rules. This portlet needs to be modified to check whether the rules should be displayed.

Modifying the Sender

The goal is to add a link to the sender ( roulImage.jsp ) to cause the rules to be displayed in the receiver. Listing 13.1 shows the code to add a link to the sender.

Listing 13.1. Adding a Link to the Sender Portlet

 <netui:anchor href="<%= request.getRequestURI()%>">     here     <netui:parameter name="_nfpb" value="true" />     <netui:parameter name="_pageLabel" value="<%= pb.getLabel()%>">     </netui:parameter>     <netui:parameter name="rules" value="true">     </netui:parameter> </netui:anchor> 

This code uses the <netui:anchor> tag to add a link, and instead of supplying an action as in previous chapters, an href attribute is supplied. The reason the action attribute isn't supplied in this instance is that the result of the link being clicked doesn't access a Page Flow action. Next, three parameters are added to the anchor tag: _nfpb , _pageLabel , and rules . The rules parameter is what the other portlet looks for to determine whether the rules should be displayed. The _pagelabel parameter informs the portal which page should be displayed when the portal is rendered. The _nfpb parameter is specific to the WebLogic Portal runtime and tells the framework that the portlets for this page should be rerendered.

Modifying the Receiver

Now that a portlet is advertising that the rules should be displayed, you need to update the rules page to use this information. Listing 13.2 shows the new portlet code checking for the URL parameter.

Listing 13.2. Checking for the URL Parameter

 <%     String rules = (String)request.getParameter("rules");     if (rules == null)         out.println("You have chosen not to display the rules");     else { %>   <h3> How to play Roulette </h3> Select a number or range and let the dealer spin the wheel. If your number comes up you win. <% } %> 

This code uses the request.getParameter() method to see whether the parameter is there; if it's not, a message is displayed. If it's there, the rules are displayed. In "Using Rules to Personalize Content," later in this chapter, you'll modify this portlet's behavior so that it doesn't appear unless the parameter is selected.

Using Backing Files

A backing file is a Java class used to do preprocessing before a portal object is rendered. Books, pages, and portlets can have backing files associated with them. This chapter focuses on portlets, but keep in mind that the methods discussed can be used for any portal object. Backing files can come in quite handy for manipulating portlet state and receiving parameters. Using backing files enables developers to continue to separate business logic from presentation logic. The business logic goes in the backing file, and the presentation logic stays in the JSP where it belongs. This section describes how to access parameters by using a backing file. The section "Controlling Portlet State" later in this chapter explains how to manipulate portlet state by using backing files.

A backing file is a misleading name, however; what you actually create is a Java class that implements the com.bea.netuix.servlets.controls.content.backing.JspBacking interface. Table 13.1 shows the different methods of the JspBacking interface and what they are used for. Note that the HTTPRequest and the HTTPSession objects are passed to all methods except dispose() , which has no arguments.

Table 13.1. Methods of the JspBacking Interface

METHOD	DESCRIPTION
init()	This method is used to access parameters that are processed in the handlePostbackData() or preRender() method. This method is run for each request made on a portlet.
handlePostbackData()	This method is used to process the information that came from the request.
preRender()	This method is called just before the JSP is rendered. It runs only if the portlet is to be displayed.
dispose()	This method is called after the JSP has been rendered and can be used to clean up objects.

The handlePostbackData() method returns a Boolean value. The idea is to return true if the results of the method change the portlet's window state. For example, as discussed later in "Controlling Portlet State," you can change the portlet's visibility, so you would return true to notify the system that the state has changed.

The preRender() method also returns a Boolean. Returning true signals to the system that the content for this portal should be refreshed. If the method returns false , the system simply redraws the cached version of the page. In this method, it's a good idea code the heavier business logic of the portlet because the preRender() method executes only if the portlet is supposed to be drawn. For example, if it's determined in the handlePostbackData() method that the portlet shouldn't be drawn, the preRender() method doesn't run. So if you access a database, it would improve performance because the database wouldn't be accessed.

With all that said, how do you use backing files with inter-portlet communication? Depending on the depth of the processing you need, you decide which methods to code. Then you simply check to see whether the parameter exists. If it does, you still need to put a flag in the HTTPRequest or HTTPSession objects so that the portlet knows there are values to display. Backing files are used again in "Backing Contexts" later in this chapter.