Known issues and restrictions with cooperative portlets
The following known issues and restrictions exist with cooperative portlets.
The pop-up menu functionality requires browsers with JavaScript on the client.
To share data, all cooperative portlets must be on the same portal page.
Click-to-Action portlets cannot use the getPortletSettings(), getServletConfig(), getServletContext(), getServletInfo() methods on the Portlet class and the getPortletLog() method on the PortletAdapter class. These objects can be retrieved by storing them during Portlet initialization or by using the PortletRequest object for the current request.
There is a bug in Internet Explorer that can cause the select drop-down box to obscure the pop-up menu when the icon is clicked. This occurs because Internet Explorer uses the operating system drop-downs that have higher priority than CSS/DHTML rendering used for the menu. See the description of the <c2a:encodeProperty/> Example for the work around.
The menus that are displayed by cooperative portlets are currently supported on the following browsers:
- Microsoft Internet Explorer 5.5
- Microsoft Internet Explorer 5.5 with Service Pack 2
- Microsoft Internet Explorer 6.0 with Service Pack 1
- Netscape Communicator 6.2
- Netscape Communicator 7.0
Use XMLAccess to import wires from an existing portal to a new portal requires a workaround because of a current design limitation. After the page is imported, portlet actions and properties required by the wires are registered, but the wires themselves might not get created.
- From the original portal, export the page containing the wires.
- On the target portal, make sure the portlets for the page are already deployed.
- Run the xmlaccess task for importing the page. The wire creation step might fail with errors after the page has been created successfully.
- View the newly created page and then re-run the import task. This time, the wires are created successfully.
If the portlets on the page were enabled for cooperation using the declarative approach, (actions and properties are declared using the WSDL file), a simpler workaround is available. Before you run the XMLAccess import task, edit ConfigServices.properties in the wp_root/shared/app/config/services directory and set the host.name and host.port.http properties to the target portal server's hostname and http port (if the install has not set them for you). The import of the page and creation of the wires should work in one step.
This design issue will be addressed in future releases.
- After a cooperative portlet application is deployed, its WSDL file is parsed and actions and properties registered persistently. Subsequent changes to the WSDL file are not picked up when the application is updated. The application needs to be uninstalled and reinstalled for the WSDL file to be re-processed and changes to be picked up.
See also