February 2009 Archives

Over the past many releases of ALUI/WCI, I've been dragging a UI customization along to properly order subcommunities and related communities. Since it looks like the bug that my customization addresses won't be going away any time soon, I thought I'd share it.

In Plumtree 5.x, subcommunities and related communities displayed in alphabetical order. This made sense for humans, the predominant users of the portal. Once G6 was released though, this ordering was lost, and communities then ordered by object ID. This made sense for computers, but... what about the humans? I replaced the NavigationCommSectionDropDown view after putting in a bit of code that grabs the community objects and reorders them for humans.

Default UI

Human-Friendly UI (customized)

You can download the code here. The download includes a diff showing how my code varies from the 6.x view it replaces. It also includes a diff showing the minor modifications between 6.x and 10g. Based on the apparent insignificance of the 10g changes, I continue to build the customized DLL based on the 6.x code. 

To deploy this customization, add the following to %WCI_HOME%\settings\portal\CustomActivitySpaces.xml:

<libfile name="subcommalphaorder"/>
Then copy the attached DLL to these locations:



Unfortunately, WCI ships without providing an easy way to validate that the API service works properly. Some system administrators mistakenly believe the API service works if they see the message "Hi there, this is an AXIS service!" That message only confirms the service has been turned on and gives no information about whether it may have fatally failed at startup. To provide real health information for the API service, I've written the API Check application.

This application was tested on ALUI 6.1 and WCI 10gR3.

Contexts for Use

Portal administrators will most likely choose to run the API Check application within the WCI portal as a portlet. Portlet mode is always available when the API Check application is turned on. Some organizations will additionally wish to access the API Check application available outside the portal through its standalone mode. Standalone mode is most useful when the organization performs automated service monitoring such as for a load balancer and needs to see the status without logging into the portal.


In portlet mode, this application presents no security risks. The application will retrieve a login token from the portal's request allowing API Check to connect to the system as the calling user. This is the recommended approach. However, in standalone mode, there is a security risk because standalone mode requires a credential for a portal user be stored within the applications's web.xml file. This should be avoided when possible. If however you do choose to enable standalone mode, then be sure to use the credentials of a user with minimal rights to the portal. No special priviledges need be given to this account, and the account certainly should not have any administrative rights. The automated monitoring should scan for "DBQuerySuccess" to determine the service is up.


This application runs adjacent to your existing %WCI_HOME%\ptws\10.3.0\webapp\ptapi.war file so that it will start and stop as the API service starts and stops. To install:
  • Place apicheck.war into the API service's webapps directory.
  • Import apicheck.pte into your portal. That PTE file is located within apicheck.war's install-resources directory. You can get there via http://localhost:11905/apicheck/install-resources/APICheck.pte (using an appropriate host). The PTE file will create an administrative folder, a community, a remote server, a web service, and a portlet for the API Check application.
  • From the portal admin interface, edit the API Check remote server to go to the proper address.
  • Browse to the API Check community to verify the portlet works.

Optionally, follow these additional steps if you wish to use the standalone mode:

  • Make sure you have the credentials for a portal-based user with low privileges in the portal.
  • Unpack apicheck.war
  • Edit WEB-INF\web.xml such that the values for username and userpass represent the low-rights account that should connect
  • Repack apicheck.war with the new web.xml file
  • Restart the API service
  • Browse to http://localhost:11905/apicheck/index.jsp to validate that it works.

Get the Code

This application is available for download here.

Note: The code was updated on March 20 09 to test the search API with a lookup of communities (fast) instead of users (potentially slow). Read more.

API Check in Portlet Mode


API Check in Standalone Mode

An Invisible Portlet

| | Comments (2)
I had heard of them before, but I had never seen them: Invisible Portlets. Now I can write them.

It turns out there can be a decent use case for an invisible portlet. I wanted to put a stylesheet on a page through a portlet, but I didn't want to have to tweak any of the other portlets to do it. And since the only purpose of my portlet is to deliver a stylesheet, I didn't want the portlet to show up with a header or a title. Perhaps you'll want to use this approach to put some JavaScript on the page for tracking purposes. In any case, the code is pretty simple.

The concept is that when it displays on the page, each portlet object renders with a class ID to let you manipulate it directly. In some cases, you might change the font in the title bar, but in this case, I'm taking the entire region and making it invisible. If you set it invisible through display=none, then it will not be visible to the user, but JavaScript and style instruction still apply to the page.  I use the $$TOKEN$$ concept to access the portet object ID, and that is used in the class ID. Here it is:

<pt:namespace pt:token="$$TOKEN$$" 
xmlns:pt='http://www.plumtree.com/xmlschemas/ptui/'/> <script> alert("Portlet $$TOKEN$$ will magically disappear!"); document.getElementById('pt-portlet-$$TOKEN$$').style.display = 'none'; </script> <link type="text/css"
rel="StyleSheet" lang="en" ></link>
For demonstration purposes, that code includes an alert line that will cause the portlet to first notify you that it's really live on the page and then after you acknowledge it, it disappears. You will most likely want to customize the alert message by deleting it :-P

The code is live on this web server, so you can load it into your portal for a look if you'd like. Find it at http://blog.billbenac.com/code/disappearing.portlet.html.


Update: A Better Approach

Thanks to Steve who pointed out a better way of getting the result I described above. He suggested setting the display to none in CSS directly rather than through JavaScript. That approach would look like this:

<pt:namespace pt:token="$$TOKEN$$" 

Portlet $$TOKEN$$ should be invisible through CSS.

#pt-portlet-$$TOKEN$$ { display:none; }