Known Rich Client Platform limitations and differences

Portlet Factory, Version 6.1.2

Known Rich Client Platform limitations and differences

There are several known limitations between supported rich client platforms.

While IBM® Lotus® Expeditor and Lotus Notes® 8 support a JSR168 portlet container and Property Broker, they are NOT a full WebSphere Portal. Just as you cannot use WebSphere Portal-specific APIs in the WAS6.1 JSR168 portlet container, you cannot use WebSphere Portal-specific APIs (PUMA, for example) in the IBM Lotus Expeditor and Lotus Notes 8 JSR168 containers. Known WebSphere Portal-specific APIs that are not available on IBM Lotus Expeditor and Lotus Notes 8 include but may not be limited to:

PUMA User/Group management
Credential Vault
Portal provided content management services

The IBM Lotus Expeditor and Lotus Notes 8 portlet container support the Edit/Personalize mode of editing portlet preferences, but not the edit defaults "Shared Settings" or "Configure" portlet modes and preference levels that WebSphere Portal supports. Portlets that rely on Configure or Shared Settings (also known as edit defaults, to developers) may have to be modified to not rely on those portlet modes in rich client platform environments. An example might be to use the edit mode or external configuration properties instead for portlets that need to run on a rich client platform.
The default Java VM that ships with IBM Lotus Expeditorr (jclDesktop) does not support AWT or Swing, so upgrade your IBM Lotus Expeditor to use the J2SE Java VM (available on the IBM Lotus Expeditor DRE update site on your IBM Lotus Expeditor product media), to use WebCharts (the 3rdParty charting jar relies on AWT/Swing classes that only exist in a full Java VM).
WebSphere Portlet Factory has the ability for push a deployment WAR out to WebSphere Portal when you want to deploy it. IBM Lotus Expeditor and Lotus Notes 8 instead use the Ecliipse model where you tell the platform where to read/pull the deployment from. While WebSphere Portlet Factory Designer builds the WAB, Feature and Update Site, IBM Lotus Expeditor or Lotus Notes 8 must provision from that update site, rather than having the designer push it out to IBM Lotus Expeditor/Lotus Notes. This could cause a high network and server demand if you consider that there may be hundreds of IBM Lotus Expeditor or Lotus Notes clients that may want to download a portlet WAB, instead of using portlet WAR that you push to one or more portal servers.
If you build composite applications for IBM Lotus Expeditor and Lotus Notes 8, the portlets are actually running in multiple embedded browsers within the rich client platform, rather than in one browser as is the case with portal application pages. The benefit to this is that performing an action in one portlet does not force the other portlets on the page to re-render. The disadvantage to this is that portlet based applications that rely on the otherwise undesirable behavior of re-rendering all portlets on the page when a single portlet is accessed will perform differently on the rich client platforms. For example where the portlet receiving the action updates a shared variable that all other portlets on the page use when rendering their view, the other portlets will not automatically be rendered again, so if they were relying on doing so, then either the portlets or portlet application needs to be modified to not rely on that behavior, or you need to use a rich client platform supported portlet to portlet communication mechanism like property broker to communicate between portlets.
Since IBM Lotus Expeditor and Lotus Notes 8 run on client machines, and it is not efficient to have an administrator to configure JDBC datasources on every client machine, the IBM Lotus Expeditor and Lotus Notes 8 rich client platforms configure datasources using plugins, rather than through a platform administrator interface. More information on configuring datasources for IBM Lotus Expeditor based rich client platforms, is available in the IBM Lotus Expeditor Developers Guide.
Java 1.4.x on Windows appears to have a 256 character filesystem path limitation, and the IBM Lotus Expeditor platform installs extensions fairly deep on the filesystem. If you run into file not found issues due to file paths greater than 256 characters, try upgrading to the Java J2SE5 JVM provided with the IBM Lotus Expeditor DRE update site, which does not appear to be susceptible to these path limitations.

Parent topic: Overview of IBM WebSphere Portlet Factory support for rich client platforms

Library | Support |