Known issues and restrictions with cooperative portlets

 

+
Search Tips   |   Advanced Search

 

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.

  • IBM only: Cooperative 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.

  • 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

    • Netscape Communicator 7.2

  • Using 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.

    1. From the original portal, export the page containing the wires.

    2. On the target portal, make sure the portlets for the page are already deployed.

    3. Run the xmlaccess task for importing the page. The wire creation step might fail with errors after the page has been created successfully.

    4. 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.

  • IBM portlets only: Cooperative portlets that need to implement the doTitle() method of the IBM portlet API must follow some additional steps. This is because the wrapper portlet for cooperative portlets does not implement PortletTitleListener to prevent the container from always calling each cooperative portlet's doTitle() method, regardless of whether the portlet implements PortletTitleListener.

    If the portlet needs to implement doTitle(), it must extend the base PortletWrapper class, implement PortletTitleListener in the extension, and use this as the wrapper class in web.xml.

    Example 

    
package com.myco.mywrapper;
import org.apache.jetspeed.portlet.*;

public class MyPortletWrapper extends com.ibm.wps.pb.wrapper.PortletWrapper 
                              implements PortletTitleListener
{
  Portlet appPortlet_ = null;

  public void doTitle PortletRequest(request, PortletResponse response) 
                                     throws PortletException, IOException
  {
    Portlet appPortlet_ = getApplicationPortlet();
    try
      {
      ((PortletTitleListener)appPortlet_).doTitle(request, response);
      }
    catch (ClassCastException e)// should not happen, as this class should 
                                // be provided only if the app portlet 
                                // implements PortletTitleListener
    {
      response.getWriter().print(request.getPortletSettings().getTitle(request.getLocale(), request.getClient()));
    }
  }                      
}

    To specify the new wrapper portlet in the web.xml, change the standard wrapper for cooperative portlets: 

       <servlet-class>com.ibm.wps.pb.wrapper.PortletWrapper</servlet-class>

    to the new wrapper class: 

       <servlet-class>com.myco.mywrapper.MyPortletWrapper</servlet-class>

  • IBM portlets only:Click-to-action menus show action names instead of caption keys if the portlet does not provide a resource file for the language. For example, if the portlet provides a resource file for de, menus will display the correct caption as long as if the portal's default language setting is de or the user's browser setting is de. However, if the user's browser setting is changed to en, the portlet's C2A menus will not show the English caption (an English caption has not been provided) nor even the caption key, but the actual name of the action.

    The solution is for the portlet to provide a resource file for the language as described in Internationalization.

  • IBM portlets only: Changes WSDL files are not processed when updating the portlet application. To see updates on WSDL files, uninstall and reinstall the portlet.

  • IBM portlets only: To use Click-to-Action popup menus on <AREA> tags placed on top of an image map, accessibility enhancements must be disabled in order to have the menu render in the correct place. For example, if in a JSP file the variable "onClickMarkup" represents the markup returned by the property broker for the onClick action, then the JSP will have a line that looks like this:

    <AREA shape="circle" coords="1,2" onClick="<%=onClickMarkup%>">

    This line needs to be changed as shown below in order to disable these accessibility changes and bind the rendering of the menu to the location of the cursor:

    <AREA shape="circle" coords="1,2" onClick="window.c2a_bind_to_cursor=true;<%=onClickMarkup%>window.c2a_bind_to_cursor=false;">

  • IBM portlets only: Netscape interprets a CTRL-click as a request to spawn a new browser window. For this reason, ALT-click must be used instead of CTRL-click on Netscape for obtaining the automatic wiring dialog.

 

See also

Home |

 

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