Known issues and restrictions with cooperative portlets

 

+

Search Tips   |   Advanced Search

 

The following known issues and restrictions exist with cooperative portlets.

  • The property broker does not support anonymous users. That is, for portlets on a page to transfer properties, the user must be logged in.

  • The pop-up menu functionality requires browsers with JavaScript on the client.

  • For sample Struts WAR files including pbstrutsExample.war, when importing into Rational Application Developer V6 reports broken links. This warning message can be ignored.

  • Rational Application Developer lists WS-I warnings for wsdl:binding errors. WS-I compliance warning messages will be displayed in the Problems view for Click-to-Action enabled portlets. We can ignore them in the Click-to-Action WSDL resources. To prevent these warning messages from being displayed...

    1. Select Window, then Preferences, then Workbench, and then Capabilities.

    2. Expand Web Service Developer and ensure that Web Services Development is selected.

    3. Click Apply.

    4. Select Window, then Preferences, then Web Services, and then WS-I Compliance.

    5. Set the compliance levels to Ignore compliance.

    6. Click Apply.

    To remove the compliance warnings from the Problems view open the project's pop-up menu in the Project Explorer and select Run Validation.

  • When multiple cross-page wires are triggered at the same time to different target pages, the first target page will have priority. Only the wires going to the first target page will work. The other events will be discarded.

  • Wires created on a root page may not be created by default on any child derived page. They have to be recreated on the derived page.

 

Issues and restrictions related only to IBM portlets

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

  • 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

    Figure 1. Implementing doTitle()

    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>
    

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

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

  • 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;">
    

 

Related concepts

Struts Portlet Framework

 

Related information

http://www.w3.org/TR/wsdl
http://www.w3.org/TR/xmlschema-2/