Portlet Development Guide

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Local Interportlet Communication

Interportlet communication (IPC)—also called portlet-to-portlet communication—allows multiple portlets to use or react to data. For example, you might want to use IPC in a self-service or sales implementation where common data elements, such as order ID or customer ID, are used across multiple projects. All portlet types supported by WebLogic Portal can implement IPC. Examples of IPC include:

IPC in WebLogic Portal is based on the use of event handlers—objects that listen for predefined events on other portlets in the portal and fire actions when that event occurs. You can set up interportlet communication in two ways: using the Workshop for WebLogic interface, or using the WebLogic Portal API.

This chapter includes a tutorial-based example of establishing interportlet communications using an out-of-the-box portal event handler (Basic IPC Example). This example will familiarize you with event handlers and show you some of their common uses.

This example is specific to interportlet communications within a single portal web project. For information on establishing IPC with federated portals (WSRP), refer to the Federated Portals Guide.

Note: If you want to use asychronous rendering with IPC, consider using asynchronous desktop rendering, as discussed in the chapter “Designing Portals for Optimal Performance” in the Portal Development Guide. Note that IPC is not compatible with asynchronous portlet rendering, as discussed in Asynchronous Content Rendering and IPC, but workarounds exist for some use cases.

This chapter includes the following sections:


Definition Labels and Interportlet Communication

IPC behavior is based on portlet definition labels; that is, all portlet instances of a given .portlet file respond to the same events. You can use the event handler options Only If Displayed and From Self Instance Only to discriminate among the instances of the same .portlet file. For a description of these options, refer to Portlet Event Handlers Wizard - Add Handler Field Descriptions.


Portlet Events

Portlet events (not to be confused with page flow events) allow portlets to communicate. One portlet can create an event and other portlets can listen for that event. A portlet event can also carry accompanying data called a payload, where the payload is a serializable Java object.

This section contains the following topics:

Event Handlers

Event handlers listen for events raised on subscribed portlets and fire one or more actions when a specific event is detected. An event handler tag is a child of the <portlet> tag, and a portlet can have any number of events associated with it. Table 9-1 lists the event handlers that are available on the Add Handler menu of the Portlet Event Handlers wizard:

Table 9-1 Event Handlers
Handle Generic Event
Allows you to set up an event that will fire in several possible situations. For details, see Generic Event Handlers below.
Handle Portal Event
Responds to a portal framework event on a portlet by firing an action.
Handle Custom Event
Responds to an event that you define.
A custom event handler is triggered by an event and can pass a developer-defined payload or fire any predefined action. Custom event handlers can be triggered declaratively or they can be based on a methods called in a backing file. You can specify that an event should be handled by a method in a backing file.
Handle PageFlow Event
Fires an action when an event occurs on that portlet.
You can define a page flow event handler (on that portlet) that responds to these events and performs actions, such as to notify other portlets (that is, raise a custom event) or invoke a backing file call-back method, and so on.
Handle Struts Event
Responds to an event on a portlet by firing a struts action.
Handle Faces Event
Responds to an event on a JSF portlet by firing a JSF action.

Generic Event Handlers

The generic event handler, with an event attribute value of myEvent, will be triggered on the following conditions:

Using a generic event handler allows you to more effectively decouple your portal design, because your application does not need to know the source or type of an event. You can change the portlet type (for example, from a page flow portlet to a JSP portlet, with a backing file firing custom events) without affecting how you events are processed.

Event Types

An event action depends upon the type of event being raised. Except for portal events, all other events can be identified in the Events field on the Portlet Event Handlers Wizard, as described in Portlet Event Handlers Wizard Reference. Events available with the portal event handler are listed in Table 9-2.

Table 9-2 Events Available to a Portal Event Handler
This event...
Fires an action when the portlet...
Becomes visible
Ceases to be visible
Is minimized
Is maximized
Returns to its normal state from either a maximized or minimized state
Is deleted from the portal
Enters the help mode
Enters the edit mode
Enters the view mode
Is refreshed
The onInit event is broadcast once per portal request. Use this event if you want to define an event handler that is always executed on every portal request.
This event is fired when a Look & Feel is re-initialized. This happens whenever the Look & Feel is dynamically changed, such as when any of the reinit() methods on a PortalLookAndFeel object are called. See the PortalLookAndFeel class Javadoc for more information about the reinit() methods.
For instance, if you capture information about the Look & Feel, you need to know when the Look & Feel changes so that you can refresh it with the captured information. This event provides that notification.
Mode change to the custom mode CustomEvent
Refer to Event Handlers.

Event Actions

Event handlers fire an action on the host portlet when that handler detects an event from another portlet in the application (or possibly the same portlet, for example in the case of a page flow portlet). For example, when the user minimizes the appropriate portlet, a portal event called onMinimize might cause the handler listening for it to fire an action that invokes an attached backing file.

Table 9-3 lists the event actions available for portlets.

Table 9-3 Event Actions
This action...
Has this effect...
Change Window Mode
Changes the mode from its current mode to a user-specified mode; for example, from help mode to edit mode.
Change Window State
Changes the state from its current state to a user-specified state; for example, from maximized to delete state.
Activate Page
Opens the page on which the portlet currently resides.
Fire Generic Event
Fires a user-specified generic event.
Fire Custom Event
Fires a user-defined custom event.
Invoke BackingFile Method
Runs a method in the backing file attached to the portlet. For more information on backing files, refer to Backing Files.

Portlet Event Handlers Wizard Reference

The Portlet Event Handlers wizard included in Workshop for WebLogic allows you to implement several types of event handlers and actions without programming. The following steps summarize the process of setting up an event handler using the wizard:

  1. Select a type of event handler to create.
  2. Determine the portlets to which that handler will listen.
  3. Select an event for which the handler will listen.
  4. Select and configure an action to fire when the event occurs.

The following sections describe the dialogs of the wizard and provide information about the information required in each field of the dialogs.

For a specific procedural example of how to use the event handler wizard, refer to Basic IPC Example.

Portlet Event Handlers Wizard Dialogs

You can open the Portlet Event Handlers wizard in two ways:

Note: If no event handlers have been added, the Event Handler field indicates that. If any event handlers have been added, the field indicates the number that currently exist.

The wizard appears, as shown in Figure 9-1.

Figure 9-1 Portlet Event Handlers Wizard

Portlet Event Handlers Wizard

When you click Add Handler, the event handler drop-down menu allows you to select a handler; to add an action, click Add Action to open the event action drop-down menu.

Based on your selection, the dialog box expands, displaying additional fields that you can use to set up the handler or action. Figure 9-2 shows an example of the expanded dialog for adding an event handler.

Figure 9-2 Expanded Event Handlers Dialog

Expanded Event Handlers Dialog

Portlet Event Handlers Wizard - Add Handler Field Descriptions

Table 9-4 explains the fields in the Add Handler dialog and how your selections affect the behavior of the event.

Note: WebLogic Portal attempts to validate the settings of the Event Handlers dialog. You will receive an error message if any problems are detected. For detailed information on the WebLogic Portal validation framework, see the WebLogic Portal Development Guide.

Table 9-4 Portlet Event Handlers Wizard - Add Handler 
Event Label
Required. This identifier can be used by the <filterEvent> tag in the portal file to distinguish multiple event handlers in the same portlet.
Only If Displayed check box
Optional. Indicates that the portlet to receive the event must be on the current page and not minimized or maximized—the portlet’s content must be currently in a rendered state. (Remember that the user must also be entitled to see the portlet.) The default is true.

Note: If the event is <handlePortalEvent event=”onMinimize” fromSelfInstanceOnly="true"> then it is logically impossible for this event to fire if onlyIfDisplayed="true".

From Self Instance Only checkbox
Optional. Defines whether the handler for a given portlet instance is invoked only when the source event originates from that instance. The default is false.
If From Self instance Only is set to true, any Listen To values are ignored.
Listen To (wildcard)
Identifies the portlet(s) that this portlet can listen to. The values include:
  • Any – Listens to events fired from any portlet in the portal.
  • This – Listens to events fired from the currently selected portlet.
  • Selected Portlets – (default) Listens to events fired from selected portlets only. Click the ... button in the Listen To (portlets) part of the dialog to select portlets.
  • This and Selected Portlets – Listens to events fired from the currently selected portlet and portlets selected in the Listen To (portlets) part of the dialog.
Listen To (portlets)
Optional. Allows you to specify the portlets that this portlet can listen to. You can choose a .portlet file from the file system by clicking the ... button). When you select a .portlet file and click OK, the portlet is added to the Listen To list. This part of the dialog is only enabled if you chose either the Selected Portlets or This and Selected Portlets option in the Listen To (wildcard) menu.
Caution: The values that you enter here are not validated. A typo in either an event name or a definition label can be very difficult to resolve later.
You can type a portlet name in the field and click Add, or click the browse button to navigate to the portlet for which you want to listen.
Event or Action
Depending on the event handler you added, you will choose an event or an action for which the portlet will listen. For example, if you added the HandlePortalEvent handler, you can use the Event drop-down menu to select portal events, such as the onRefresh event. If you choose a handler that exposes actions, type the name of the action in the Action field. For example, if you chose HandlePageFlowEvent, you could type submitReport. The submitReport action of the page flow is now visible in the Action drop-down menu.

Portlet Event Handlers Wizard - Add Action Field Descriptions

The available fields for the action depend on the type of action that you select. Table 9-5 explains the possible fields in the expanded Add Action dialog and how your selections affect the behavior of the action.

Table 9-5 Portlet Event Handlers Wizard - Add Action
Change Window Mode
Enter the value of the new window mode.
Change Window State
Enter the value of the new window state; possible values are normal, minimized, maximized.
Activate Page
This action activates the page on which the portlet <portlet_def_id> currently resides. This action will fire only when triggered during the handlePostBack life cycle.
Do not select the Activate Page action if the Only If Displayed check box is selected. Logically, if the portlet is responding to the event only if it is displayed, the page that it is on must be active anyway.
Invoke Struts Action
Use this selection to cause a struts action to be raised. The value must be an unqualified name of a struts action defined in the embedded content. This action is only available on the menu for struts portlets.
Fire Generic Event
Use this selection to cause a generic event to be raised.
Enter the name of the generic event.
Fire Custom Event
Use this selection to cause a custom event to be raised.
Enter the name of the custom event.
Invoke BackingFile Method
Use this selection to cause a backing file method to run. Enter the name of the method that you want to invoke. This action is only available on the menu if a backing file is configured for the portlet.
Invoke Page Flow Action
Use this selection to cause a page flow action to be raised. This action is only available on the menu for page flow portlets.
Invoke Faces Action
Use this selection to cause a JSF action to be raised. This action is only available on the menu for JSF portlets.

JSF Events

This section explains how to add JSF events and listeners to portlets.

To add a faces event to a JSF portlet:

  1. In the Property view of the portlet, select Java Server Faces (JSF) Content > Faces Events.
  2. In the Faces Events dialog, add an name/action pair. The Event Name identifies the event to event listeners. Note that events are referenced by name, not by path. The action specifies the Faces viewroot ID of the action. Workshop for WebLogic adds tags to the portlet similar to those shown in Listing 9-1.
  3. Listing 9-1 Sample facesEvent Tag
        <netuix:facesContent contentUri="/portlets/myJsf.faces"
                <netuix:facesEvent action="/portlets/bar.faces" eventName="bar"/>

To handle a faces event and invoke an action, use the Portlet Event Handlers wizard as discussed in Portlet Event Handlers Wizard Reference. When specifying the Event to listen to, use the event name specified in the facesEvent tag in the JSF portlet (the eventName attribute of the facesEvent tag). For example, in Listing 9-1 the eventName is bar.

Listing 9-2 shows the handleFacesEvent tag that is created when you add a Faces event handler to a JSF portlet. The event handler is listening for an event called bar. (Note that you can use eventName="*" to handle any Faces event that is fired.) The event handler then invokes a JSF action.

Listing 9-2 Faces handleFacesEvent Tag
<netuix:handleFacesEvent eventLabel="handleFacesEvent1" eventName="bar"
    fromSelfInstanceOnly="false" onlyIfDisplayed="true"
    <netuix:invokeFacesAction action="/portlets/myportlet.faces"/>

When working with JSF events, note the following:


IPC Example

This section contains the following topics:

Before You Begin - Environment Setup

Before you use the interportlet communication example in this chapter, you must have an existing portal development environment, consisting of a domain, Portal EAR project, Portal Web project, Datasync project, and portal. To complete the pre-requisite tasks, perform the tasks described in the Getting Started with WebLogic Portal tutorial, using the information in Table 9-6 to enter the necessary values.

  1. Create a Portal domain (server).
  2. Create a Portal EAR project.
  3. Associate the EAR project with the server.
  4. Create a Portal web project.
  5. Create a portal.
  6. Table 9-6 IPC Example - Environment Setup Values 
    Setup Information
    Domain Configuration Wizard - Welcome
    Create a new WebLogic domain (the default)
    Domain Configuration Wizard -
    Select Domain Source
    In the Generate a domain configured automatically to support the following Oracle products list, select WebLogic Portal.
    When you do this, other components are selected automatically; keep all of them selected.
    Domain Configuration Wizard -
    Configure Administrator Username and Password
    User name: weblogic
    User password: weblogic
    Confirm user password: weblogic
    Domain Configuration Wizard -
    Configure Server Start Mode and JDK
    Development Mode (the default)
    JRockit SDK
    Domain Configuration Wizard -
    Customize Environment and Services Settings
    No (the default)
    Domain Configuration Wizard -
    Create WebLogic Domain
    Domain name: ipcDomain
    Domain location: Accept the default, or specify another directory on your system.
    Portal EAR Project Wizard
    EAR Project Name: ipcEAR
    Switch to the Portal Perspective if you are not already using it.
    Servers view
    Right-click the server in the Servers view and select Add and Remove Projects
    Associate the ipcEAR project with the portal domain ipcDomain.
    Portal Web Project Wizard
    Web Project Name: ipcTestWebProject
    In the Add project to an EAR checkbox: Check the box and add to ipcEAR
    Portal Wizard
    Right-click the ipcWebProject/WebContent folder and select New > Portal
    Portal Name: ipcPortal

With a development environment set up, you can complete the steps described in this section:

In this exercise, you create individual page flows, portlets, JSPs, and backing files to establish interportlet communications within the portal project. You then add these portlets to a portal and test the project to ensure that communication is successful.

Basic IPC Example

This section describes the process of setting up interportlet communications between two portlets by using the Portal Event Handlers wizard in Workshop for WebLogic. This is a simple example in which minimizing one portlet changes the text string in another portlet in the portal.

You should become familiar with the Portal Event Handlers Wizard and backing files before attempting to replicate this example. For more information about the wizard, refer to Portlet Event Handlers Wizard Reference. For more information on backing files, refer to Backing Files.

This exercise includes five main tasks:

  1. Create the Portlets
  2. Create the Backing File
  3. Attach the Backing File
  4. Add the Event Handler to bPortlet
  5. Test the Project

Create the Portlets

In this section, you create two JSP files and the JSP portlets that surface these files. You also create a backing file that contains the instructions necessary to complete the communication between the two portlets, and you add an event handler to one of the portlets. After you have created the portlets and attached the backing file, you test the project in your browser.

Note: Before continuing with this procedure, ensure that Workshop for WebLogic is running and the ipcWebProject node is expanded.
Create the JSP Files and Portlets

To create the JSP files that the portlets will surface, do the following:

  1. Under the ipcWebProject node, double-click index.jsp.
  2. index.jsp opens in the workbench editor, displaying the source code.

  3. Replace the body text with the phrase Minimize Me! as shown in figure
  4. Figure 9-3 index.jsp after Editing the Body Text in the Workbench Editor

    index.jsp after Editing the Body Text in the Workbench Editor

  5. Save the file as aPortlet.jsp
  6. Right-click aPortlet.jsp in the Package Explorer view and select Generate Portlet from the context menu.
  7. The Portal Details dialog appears (Figure 9-4). with aPortlet.jsp in the Content Path field.

    Figure 9-4 Portal Details Dialog Box for a Portlet

    Portal Details Dialog Box for a Portlet

  8. Select Minimizable and Maximizable and click Create.
  9. aPortlet.portlet appears in the ipcWebProject/WebContent folder in the Package Explorer view.

  10. In the same directory, make a copy of aPortlet.jsp and give the name bPortlet.jsp to the copy.
  11. Open bPortlet.jsp in the workbench editor if it is not already open.
  12. The XML code for the JSP file appears.

  13. Copy the code from Listing 9-10 into the JSP, replacing everything from <netui:html> through </netui:html>. This code displays event handling from the backing file that you will create and attach in a subsequent step.
  14. Listing 9-10 New JSP Code for bPortlet.jsp
    <% String event = (String)request.getAttribute("minimizeEvent");%>
    Web Application Page
    Listening for portlet A minimize event:<%=event%>

    The source should look like the example in Figure 9-5.

    Figure 9-5 Updated bPortlet JSP Source

    Updated bPortlet JSP Source

  15. Save the file.
  16. Following the same steps you used previously, generate a portlet from the bPortlet.jsp file.

Checkpoint: At this point the ipcWebProject/WebContent folder contains these files: aPortlet.jsp, aPortlet.portlet, bPortlet.jsp, and bPortlet.portlet.

Create the Backing File

To create the backing file, do the following:

  1. In ipcTestWebProject, select the Java Resources/src folder and select File > New > Folder from the main menu.
  2. The Create New Folder dialog box appears.

  3. Create a folder called backing.
  4. The folder backing will appear under ipcTestWebProject/src, as shown in Figure 9-6.

    Figure 9-6 New Backing File Folder in Package Explorer View

    New Backing File Folder in Package Explorer View

  5. Right-click the backing folder and select New > Other.
  6. In the New – Select a wizard dialog, select Java > Class, and click Next.
  7. The New Java Class dialog appears, as shown in Figure 9-7. The Source folder field auto-fills with the default path; leave it as is. The Package field auto-fills with backing; leave it as is.

    Figure 9-7 New Java Class Dialog

    New Java Class Dialog

  8. In the Name field, enter Listening and click Finish.
  9. The new Java class appears in the editor.

  10. Delete the entire default contents of Listening.java, and copy the code from Listing 9-3 into the file. Figure 9-8 shows the top portion of the Listening.java file as it should look after you paste the code into it.
  11. When you’re finished, save the file.
  12. Listing 9-3 Backing File Code for Listening.java
    package backing;
    import com.bea.netuix.servlets.controls.content.backing.AbstractJspBacking;
    import com.bea.netuix.servlets.controls.portlet.backing.PortletBackingContext;
    import com.bea.netuix.events.Event;
    import javax.servlet.http.HttpServletRequest;
    import javax.servlet.http.HttpServletResponse;
    public class Listening extends AbstractJspBacking
       static final long serialVersionUID=1L;
       public void handlePortalEvent(HttpServletRequest request,
       HttpServletResponse response, Event event)
          String attributeId= this.getPortletInstanceLabel(request) +       "_minimizeEventHandled";
    	       // NB: Use the HttpSession to pass data between lifecycle phases 
       // (that is, to the pre-render phase). Passing data between
       //     backing file callback methods using the HttpRequest or static
       //     instance variables should be avoided.
       // The portlet instance label is used to create a unique
       //     attribute name for the session attribute.

          request.getSession().setAttribute(attributeId, "minimized!");
       public boolean preRender(HttpServletRequest request, HttpServletResponse
          String attributeId= this.getPortletInstanceLabel(request) +
             if (request.getSession().getAttribute(attributeId) != null)
                // Reset the session flag
                // Pass minimize event notification to the JSP via the request.
                request.setAttribute("minimizeEvent", "Minimize event handled");
                request.setAttribute("minimizeEvent", null);
          return true;
       private String getPortletInstanceLabel(HttpServletRequest request)
          PortletBackingContext context=
          return context.getInstanceLabel();

Figure 9-8 Listening.java with Updated Backing File Code

Listening.java with Updated Backing File Code

Attach the Backing File

Now you will attach the backing file created in the previous section to bPortlet.portlet. Perform the following steps:

  1. In the Package Explorer, double-click bPortlet.portlet to open it.
  2. Click on the portlet in the editor, if needed, to display the portlet’s properties. You should see an orange border around the outside of the portlet, as shown in Figure 9-9.
  3. Figure 9-9 bPortlet with Outer Border Selected to Display Properties

    bPortlet with Outer Border Selected to Display Properties

    Tip: The Properties view is a default view in the Portal perspective. If it is not visible, select Window > Show View > Properties.
  4. In the Properties view, enter backing.Listening into the Backable Properties > Portlet Backing File field, as shown in Figure 9-10.
  5. Figure 9-10 Attaching the Backing File in the Properties View

    Attaching the Backing File in the Properties View

  6. Save the portlet file.

Add the Event Handler to bPortlet

You now add the event handler to bPortlet.portlet. This handler will be set up so that it will listen for an event on a specific portlet and fire an action in response to that event. To add the event handler, perform the following steps:

Note: bPortlet.portlet should be displayed in the Workshop for WebLogic editor. If it isn’t, locate it in the ipcTestWebProject/WebContent folder in the application panel and double-click it.
  1. Click on the portlet in the editor if needed to display its properties.
  2. In the Properties view, click in the Value column of the Event Handlers property. A browse button Attaching the Backing File in the Properties View appears, as shown in Figure 9-11.
  3. Figure 9-11 Event Handlers Button

    Event Handlers Button

  4. Click the ellipsis button Event Handlers Button to display the Portlet Event Handlers dialog, as shown in Figure 9-12.
  5. Figure 9-12 Portlet Event Handlers Dialog Box

    Portlet Event Handlers Dialog Box

  6. Click Add Handler to open the Event Handler drop-down list.
  7. From the drop down list, select Handle Portal Event.
  8. The Portlet Event Handlers dialog box expands to allow entry of more details, as shown in Figure 9-13.

    Figure 9-13 Event Handler Dialog Box Expanded

    Event Handler Dialog Box Expanded

  9. Accept the defaults for all fields except Portlet.
  10. In the Portlet field, click the ellipses button Event Handler Dialog Box Expanded.
  11. The Please Choose a File dialog appears.

  12. Click aPortlet.portlet and click OK.
  13. The dialog box closes and aPortlet_1 appears in the Listen to (portlets): list and in the Portlet field, as shown in Figure 9-14. The label aPortlet_1 is the definition label of the portlet to which the event handler will listen.

    Figure 9-14 Adding portlet_1

    Adding portlet_1

  14. Click the Event drop-down control to open the list of portal events that the handler can listen for and select onMinimize, as shown in Figure 9-15.
  15. Figure 9-15 Event Drop-down List

    Event Drop-down List

  16. Click Add Action to open the action drop-down list and select Invoke BackingFile Method.
  17. The Invoke BackingFile selection will not appear unless a backing file is detected by WebLogic Portal.

  18. In the Method field, enter handlePortalEvent, as shown in Figure 9-16.
  19. The dropdown menu for this field displays the last several values that you entered, if applicable.

    Figure 9-16 Adding the Backing File Method

    Adding the Backing File Method

  20. Click OK.
  21. The event handler is added. Note that the Value field of the Event Handlers property now indicates 1 Event Handler.

Test the Project

Test the communication between your portlets by following these steps:

Note: Before you begin, ensure that all files are saved.
  1. Select ipcPortal.portal to display it in the workbench editor.
  2. Drag both aPortlet.portlet and bPortlet.portlet from the Package Explorer view onto the portal layout, as shown in Figure 9-17.
  3. Figure 9-17 Portal Layout with aPortlet and bPortlet Added

    Portal Layout with aPortlet and bPortlet Added

  4. Save the portal.
  5. Run the portal. To do this, right-click ipcPortal.portal in the Package Explorer view and select Run As > Run on Server.
  6. At the Run On Server – Define a New Server dialog, click Finish.
  7. Wait while the server starts and the application is published to the server. The portal will render in your browser (Figure 9-18).

    Figure 9-18 ipcLocal Portal in Browser

    ipcLocal Portal in Browser

  8. Click the minimize button to minimize aPortlet.
  9. Note the content change in bPortlet, as shown in Figure 9-19.

    Figure 9-19 ipcPortal Showing the Effect of Minimizing aPortlet

    ipcPortal Showing the Effect of Minimizing aPortlet


In this example, you set up your environment and you added two JSP portlets to a local portal. One portlet, aPortlet, was fairly simple, while the second portlet, bPortlet, surfaced a more complex JSP file, used a backing file, and contained a portal event handler. When you tested the communication between the portlets, you observed how the bPortlet changed when an event occurred on aPortlet. This is called local interportlet communication.


IPC Special Considerations and Limitations

The following sections describe special considerations that you should keep in mind as you implement interportlet communications.

This section contains the following topics:

Using Asynchronous Portlet Rendering with IPC

Although IPC is not supported when asynchronous content rendering for specific portlets is enabled, WebLogic Portal provides some features that allow these two mechanisms to coexist in your portal environment. In addition, you can disable asynchronous rendering for single requests using the mechanisms described in Asynchronous Content Rendering and IPC.

Tip: If you enable asynchronous rendering at the portal/desktop level, you can use IPC without restrictions. For more information on asynchronous portal/desktop rendering, see the WebLogic Portal Development Guide.

Generic Event Handler for WSRP

Use a generic event handler to work with WebLogic Portal WSRP. To do this, first select Generic Event Handler, then select Add Action and select Window Mode|State. Then manually type in the event name—for example, onMinimize.

Consistency of the Listen To Field

Pay attention to the Listen To field when you set up the listener portlet. The portlet definition you use on the consumer must match the WSRP portlet’s portlet definition. For example, if you have “portlet_2” listening to “portlet_1”, the WSRP portlet corresponding to “portlet_1”—the proxy on the consumer—must also have its portlet definition label set to “portlet_1”. For more information on using IPC with WSRP, refer to the Federation Guide.

  Back to Top       Previous  Next