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, the declarative approach is simpler and should be used where possible, with selective programmatic calls being made to activate or deactivate actions as necessary. Programmatic registration of properties might be convenient for portlets generated by builder tools.
The setProperties() method may be used 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.
See also