12.1 Overview

 < Day Day Up > 

Cooperative portlets exchange information, react in a coordinated manner and provide menus to share information by selecting an action. Selecting such a menu item results in the execution of the actionPerformed() method on a target cooperative portlet. Figure 12-1 illustrates an example of such a cooperative portlet menu.

Figure 12-1. An example of a cooperative portlet menu

graphics/12fig01.gif

In Figure 12-1, one piece of information, for example a department number, can be sent to a target portlet displaying all employees from the selected department number or to a portlet displaying detailed information of the selected department. In addition, the cooperative portlet technology also enables the broadcast of data to multiple portlets by sending multiple property values with only one click.

The transfer of properties can be saved as wires using the Ctrl key. So the next time the user clicks the icon, the saved menu selection is used without prompting the user .

Portlet messaging versus cooperative portlets

In general, both portlet messaging and cooperative portlets can be used to share data between two or more portlets. The most important difference is that cooperative portlets are more loosely coupled than portlets using messaging. Cooperative portlets do not have to know the name of the target portlet even if they do not broadcast data. The matching of source and target portlets is done at runtime based on registered properties and actions. Cooperative portlets can also include a menu with a list of executable portlet actions. For this menu, no additional programming is needed because it is part of the C2A tag library.


12.1.1 The WebSphere Portal property broker

During runtime, the WebSphere Portal property broker is responsible for enabling cooperative portlets. This is done by matching the data type of output properties from a source portlet with the data type of input properties from one or more target portlets. Figure 12-2 shows the relationships between the two portlets and properties.

Figure 12-2. The property broker matches input and output properties

graphics/12fig02.gif

Target portlets optionally provide actions to process the properties that it receives. There is no difference between an action initiated by the portlet itself as mentioned in Chapter 5, "Action event handling" on page 181 and an action initiated by a source cooperative portlet.

Cooperative portlets can be source portlets, target portlets, or both.

  • Source portlets identify to the property broker properties which they are able to share with other portlets.

  • Target portlets identify to the property broker actions which are able to process properties contributed by other portlets.

12.1.2 Programming model

To enable your portlet for cooperation as well as a broker component, you have to wrap your portlet class with a generic wrapper portlet. This wrapper intercepts calls and interfaces with the broker. The wrapper is packaged in each cooperative portlet's WAR file.

Cooperative portlets can use a declarative or programmatic approach, or a combination, to register and publish properties to the property broker. The programmatic approach to publish properties is discussed in Chapter 13, "Advanced cooperative portlets" on page 413. The declarative approach is simpler. Few changes need to be made to existing portlets to enable them to interact with other cooperative portlets on the page. Existing portlets that already use action processing simply declare their actions to the property broker using WSDL. Figure 12-3 presents how to develop source cooperative portlets.

Figure 12-3. Steps to program a source cooperative portlet

graphics/12fig03.gif

In general terms, there are two steps at runtime to establish cooperative portlet communication:

  1. All properties must be registered with the cooperative broker. This can be done by using the declarative approach which includes the creation of a Web Service Description Language (WSDL) file and the configuration of the portlet deployment descriptor. To register properties programmatically, you can use the property broker API. Please note that registration of properties can only be done during the event phase of the request-response cycle.

  2. Notify the property broker about property changes. The easiest way to achieve this is to include the encodeProperty tag in your JavaServer Page. As an alternative, in the programmatic approach you will use the changedProperties () method to publish properties.

    Also, in the programmatic approach you have to configure a wire before you publish properties. Figure 12-4 on page 375 shows how to develop target portlets.

    Figure 12-4. Steps to create a target cooperative portlet

    graphics/12fig04.gif

To get information about changed properties, target portlets register properties and, optionally, actions with the property broker. When using the declarative approach both properties and actions are always registered. When using the programmatic approach, you can register properties without any actions.

In addition, during runtime process such programmatic target portlets are notified about property changes by using the setProperties method from the PropertyListener interface instead of the actionPerformed method.

12.1.3 Registering and publishing properties

For a portlet to be a source of data, programmers can use a custom JSP tag library to flag sharable data on their output pages. The tags require a data type to be specified as well as a specific value corresponding to an instance of this type. If you want to use wires source portlets, you must register properties by using a declarative or programmatic approach.

Target portlets associate their actions with an input property which has been declared as an XML type. The actions are declared using WSDL, with a custom binding extension which specifies the mapping from the abstract action declaration to the actual action implementation. Associated with each action is a single input parameter described by an XML type and zero or more output parameters, each described by an XML type. Each input or output parameter encapsulates exactly one property. The input property's type is used for matching the action to sources, and its value is filled in when the end user triggers the action using Click-to-Action. The output parameters, if specified, are used to automatically trigger other compatible actions (ones which can consume the same type) on other wired portlets every time the action executes (this may be used to trigger chains of related actions).

Note : The location of the WSDL file is configured as a portlet parameter.

 < Day Day Up > 


IBM WebSphere Portal V5 A Guide for Portlet Application Development
IBM Websphere Portal V5: A Guide for Portlet Application Development
ISBN: 0738498513
EAN: 2147483647
Year: 2004
Pages: 148

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net