Building click-across messaging portlets

You create portlets in Web Studio from a variety of content sources, including Web, XML, database, JSP, and Web services elements. Portal Interface supports portlets communicating with each other when they are placed on the same Portal Interface page or different pages.

EP also supports portlets communicating with each other when they are placed on different pages within the same page group. See “Building application portlets” for details.

Web Studio includes a wizard-driven graphical user interface that allows you to build messaging portlets without programming.

Messaging portlets use a “click-across” mechanism, which uses the publish-and-subscribe model. Portlets that communicate through a publish and subscribe paradigm require the sending portlet (publisher) to publish messages without explicitly specifying recipients or having knowledge of intended recipients. Similarly, a receiving portlet (subscriber) must receive only those messages in which the subscriber has registered an interest.

Not all of portlet types can be publisher or subscriber portlets. JSP portlets can only be publisher portlets and Web service portlets can only be subscriber portlets.

A portlet publishes notifications, which are received by a listening portlet subscriber. The publishing entity does not have to be aware of who or what has subscribed to its broadcasts. This allows for a flexible system where a portlet publishes multiple notices and a subscriber subscribes to multiple notices. Additionally, publishers can also be subscribers and subscribers can be publishers. A portlet can listen for an event while broadcasting another event.

When a user clicks an enabled link in a portlet with a defined event, the portlet broadcasts the event and passes along some data, such as the text on which the user clicked or the URL associated with the link. The parent page passes the event notification to portlets on the same or other pages that have registered as listeners for that event.For example, some portlets represent a series of navigation steps that are recorded during portlet creation and executed as a series of HTTP GETs and POSTs during playback. If a portlet contains CGI parameters from any GETs and POSTs, a portlet’s creator can override the CGI parameters to place input boxes above the portlet when it is played back. These input boxes allow the person viewing the portlet to enter their own data values in place of the CGI parameters.

If a portlet’s content contains tabular data, you can specify input parameters (commonly referred to as CGI parameters) during the portlet creation process.

A portlet’s creator can override the CGI parameters to place input boxes above the portlet when it is played back. These input boxes allow the person viewing the portlet to enter their own data values in place of the CGI parameters.

Figure 5-1 shows a portlet with the CGI parameter that corresponds to the Department Set ID. The value has been overridden and set to “AUS”.

When used in conjunction with click-across messaging portlets, the data passed to the portlet from the input boxes can be populated automatically from data in another portlet on the same page or a different page.

The left portlet displays a list of Department Set IDs. The right portlet lists the employees for the given Department Set ID. When a user clicks the Department IDs in the left portlet, the selected ID is sent to the listening portlet on the right. Once the data is received, the listening portlet re-executes using the new data, and captures the resulting content.

Whether the listening portlet re-executes automatically depends on how you set the Auto Submit property in the Listener Editor when you define the portlet listener. If you selected Auto Submit when you define the listener, the listening portlet re-executes immediately. If Auto submit is not selected, the listening portlet does not re-execute instantly; click Refresh on the title bar to manually re-execute the listening portlet.

For example, if the user clicks the Belgium Department ID “BEL,” the string “BEL” is sent to the right portlet as input for the Department Set ID. The right portlet replays its capture sequence using the new query value of “BEL” and returns the result—the employee list for the Belgium department.

When developing click-across messaging portlets, you are not limited to one parameter. As a portlet’s creator, you can override any number of parameters and set any number of those parameters to accept data from another portlet on the same page. Additionally, you can set any number of message events within a portlet, as explained later in this section.