Programming guidelines for cooperative portlets


It is useful to use some programming guidelines to determine which source data and target actions to expose to the property broker. Usually, any data item which is part of the portlet's data model and could be of interest to other portlets, is a candidate for an output property. It usually does no harm to register as many output properties as fit the restrictions, as the property broker incurs minimal processing overhead for processing output properties which do not have any matching actions on the page. Be alert to places in your JSPs where data corresponding to the portlet's output properties is available. Use the Click-to-Action JSP tags to identify these properties in your JSPs. Tagging all such properties maximizes the potential applicability of the portlet as it is deployed in a variety of settings.

Target actions which are to be invoked through the property broker must meet the single input parameter restriction. If the portlet action changes or accesses other state variables as a result of the action, determine if such state changes or side effects may be of interest to other portlets. If so, declare these as output parameters for the action. For example, as a consequence of executing an "Order Detail" action, a portlet may retrieve information which contains an associated tracking ID. Since this is a key which may potentially be of interest to other portlets, it may be declared as an output parameter.

In general, declarative registration using the WSDL file is simpler and should be used when both declarative and programmatic registration are options. For JSR portlets, declarative registration is the only option supported. Programmatic registration of properties may be necessary for portlets generated by builder tools.

The setProperties() method may be used instead of the action binding approach by the portlet to record a state change (by storing in a bean, for example), instead of reacting to the change immediately.

The changedProperties() method is provided for use in the setProperties() method to publish the value of an output property, but may be invoked at any point in the event phase. For actions, it is usually simpler to declare output parameters and bind the values to the request or session in the actionPerformed() method instead of using the changedProperties() method. The changedProperties() method can be used in setProperties() or when the set of output parameters cannot be anticipated during portlet development.

It may often be possible to take an existing portet, examine its actions, and declare a subset of these which meet the restrictions using WSDL, thus enabling the portlet to act as a target. The flexibility of choosing from multiple binding options for the action parameters also aids in this reverse-mapping, or bottom-up approach.

JSR compliant portlets using portlet cooperation should be programmed so that they perform correctly in JSR compliant containers other than the IBM container. This can be implemented using a boolean variable that is set depending on whether the initial access to the PropertyBrokerService interface succeeds. Subsequent code making calls to this interface is guarded using this variable. All other parts of the cooperative portlets programming model reuse existing JSR interfaces and objects.

When developing cooperative portlets that will be supplied to a third party, provide documentation on the set of properties generated and received by your cooperative portlets. This will enable the third party to develop their own portlets that take advantage of the portlets you provided.

 

See also

Home |

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.