Time to switch search keywords?

The data below are from overture.com. They state how many times the following terms are currently being used in search queries. (I’m not sure if the data collected are only from Google or if they include multiple search engines.)

680 plumtree
67 plumtree software
46 plumtree portal

305 aqualogic
31 aqualogic bea

According to these data, which show that more than twice as many people are searching for “plumtree” than for “aqualogic,” it’s not quite time to insert AquaLogic keywords into bdg-online.com and/or re-brand the bdg Plumtree blog as the bdg AquaLogic blog.

Adoption of the new names takes time, but we’re getting closer.

ALUI Portlet Pagination Cookbook

A coworker asked me how to write Plumtree portlet pagination (i.e. showing records in a UI and allowing the user to move from page to page, n records at a time) the other day and the ensuing discussion made me rethink how I’ve always done this and consider some new options. In this post, I attempt to shed some light on a very simple concept that turns out to be quite interesting in terms of implementation.

First, let’s consider some of the ways developers typically add pagination to standard web applications, forgetting about portals and portlets for a moment. Let’s call n your page size, i your page number and t the total number of records. On the first page, you might see n records laid out with alternating row colors and a 1-n of t marker to show you were you are, e.g. Now Showing Records 1-5 of 45. There’s probably also a next button and a back button (grayed out for now), a first page button (also grayed out), a last page button and maybe even a “fast-forward” button to move forward several pages at a time.

A very easy way to implement this in a standard (non-portal) MVC Java/J2EE Web application would be to carry some state, say i (the page index), on the querystring. For example, say you have a record viewer servlet called “RecordView” running on a Java-enabled Web application container such as Tomcat. You could have something like http://bdg-plumtree:8080/bdg-plumtree-context/RecordView as your URL. Your servlet code snippet might look something like this:

import javax.servlet.*;
import javax.servlet.http.*;


private Model model;

protected void doPost(HttpServletRequest request,
                      HttpServletResponse response)
                        throws IOException {

    //if you didn’t specify a page argument, display the
    //first page (pageIndex = 0)
    int pageIndex = request.getParameter("i") == null ? 0 :

    //make a call into the data model to get the i-th page
    //and put the results in the request
    request.setAttribute("results", model.getResults(pageIndex));

    //forward to your view (JSP)
    request.getRequestDispatcher("view.jsp").forward(request, response);

In the view, you would simply print out the results, line-by-line, perhaps alternating row colors to make it easier to read. Then you need to display the little marker that tells you what page you’re on and the buttons to get next/back/to the end/etc. The logic to figure out what buttons to display and which buttons to gray out is a little involved, but it’s mundane enough that I don’t think I need to cover it here. The important part for this discussion is what’s in the links that actually take you forward and (soon) back. The answer there is simple enough — just create links that append the appropriate querystring and you’re all set. Here’s an example:

<a href="http://bdg-plumtree:8080/bdg-plumtree-context/RecordView?i=<%=i + n%>">Next</a>

So far so good.

The problem is that when you try to do this in an ALUI portlet, you don’t have direct access to the querystring, so you can’t use this approach. You need to store the variable i using some kind of state mechanism. Here are your options:

  1. The HTTP session
  2. A portlet setting
  3. A session setting (G6 and up only)

There are tradeoffs between #1 and #2 but #3 offers a good compromise. Let me explain.

If you use the HTTP session, your users’ page setting (i), will only persist for the life of the session, which is probably desirable. But, if you’re using the Plumtree caching model for portlets (such as expires or last-modified/etag caching), you can’t cache this portlet at all, which is definitely not desirable. The reason is that every page, regardless of the value of i, will have the same cache key.

To implement session-based pagination, you only need to change two lines of code:

becomes request.getSession().getAttribute("i") and your anchors that control the moving from page to page now need to point to a different controller servlet. (Remember, you don’t have control over the query string any more in portletland).

<a href="http://bdg-plumtree:8080/bdg-plumtree-context/ChangePage?i=<%=i%>">Next</a>

The ChangePage servlet simply sets the session attribute and then calls return to portal as shown here:


The only way to unique-ify the cache key, therefore caching your portlet appropriately, is to go with approach #2, the portlet setting. Now, when users advance i, they will be creating a new cache entry for each value of i (since settings are always part of the cache key). The drawback is that the users’ page settings (i) will persist longer than the life of the session. In other words, they could be browsing page 5, then they could leave the portal for several days, come back, and still be on page 5!

For your view:

  response).getRequest().getSettingValue(SettingType.Portlet, "i");

And for your ChangePage servlet:

  response).getResponse().setSettingValue(SettingType.Portlet, "i", request.getParameter("i"));
PortletContextFactory.createPortletContext(request, response).getResponse().returnToPortal();

G6 offers a nice compromise: the session setting. (If I had to guess, I would say the session setting was designed expressly for pagination.) With a session setting, you get the best of both worlds: a page setting that lasts only for the duration of the session but also a unique cache key so that you can effectively cache your portlet.

For your view:

  response).getRequest().getSettingValue(SettingType.Session, "i");

And finally, for your ChangePage servlet:

  response).getResponse().setSettingValue(SettingType.Session, "i", request.getParameter("i"));

All of these methods have one drawback — they refresh the entire page on every portlet pagination click. So . . . stay tuned for an upcoming post on AJAX-based portlet pagination.


dev2dev comments are listed in date ascending order (oldest first)

  • This is a good start for everyone on Java. If you are like me and are a .NET developer at heart, you will be glad to know the .NET Web Control Consumer supports the use of a MS data grid control. All that is needed is for the developer to drag one of these objects onto the form, hook it up to a data source, and presto, you get pagination, storability, edit, and any other thing you always wanted from a table.

    Andrew Morris – [email protected]

    Posted by: drews_94580 on August 15, 2006 at 2:03 PM

  • It’s true — in many ways, .NET is way ahead of Java. I have only a little experience with the .NET Web Controls and the Control Consumer, but from what I’ve seen, there’s a lot of power and flexibility there. My post was making the “I want to roll my own pagination in Java” assumption. 🙂

    Posted by: bucchere on August 16, 2006 at 8:30 PM

Caveat Emptor: Using Varpacks in Pluggable Navigation

I got burned by this today, so I thought I would share it with you all. I had a perfectly good and working pluggable navigation that loaded a remote portlet in the left navigation pane. The only problem was that I had hardcoded the portlet ID and I wanted to make it configurable. So naturally I put the portlet ID and some other settings in a varpack, which is a reasonable thing to do. I then called my varpack from the constructor of my pluggable navigation class that implements IView.

Then I spent the next hour banging my head against the keyboard.

I kept getting a nasty Invocation Target Exception coming out of the reflection methods used to pre-load pluggable navigations. Eventually, using the handy space=MemoryDebug trick, I was able to ascertain that my varpack XML syntax was wrong and my varpack was looking empty to ALUI. So I fixed that and still, I got an ITE.

Then I looked at a PTSpy log and I discovered that the loading order of objects in ALUI was to blame. The portal loads built-in varpacks first, then it loads pluggable navigations, then it loads custom varpacks. So you can’t use the varpack from the IView constructor. I moved it to the Display method and everything started working again. Phew. 😐

So, shame on me for trying to use a custom varpack before it was loaded. Make sure not to make the same mistake!

Hello World + Portlet vs. Native Navigation

Hello world! This is my first post on my shiny new dev2dev blog and needless to say, I’m very pleased to be blogging here and to be given the opportunity to contribute to this prestigious and active community.

That being said, I hope you’ll find my contributions worthwhile. I plan to address mostly technical topics pertaining to AquaLogic User Interaction or ALUI (pronounced ah-LOO-eee by those in the know) with the occasional foray into the business side of ALUI and portals in general. I’ve been working with the ALUI (formerly Plumtree) products now for almost 10 years, but I also know a bit about Weblogic and I want to learn more about the other products in the AquaLogic family. So watch this space for news about all your favorite BEA products!

Okay, on to the topic at hand — navigation. Once upon a time (pre Plumtree 5.0), UI customization meant hacking through layers of ASP or JSP includes to find the right file and then changing this and that and trying not to break anything. And then when upgrade time came, you somehow had to merge all your changes out of the old UI code and into the new. It was a black art at best, a total goat rodeo at worst.

Enter Plumtree 5.0, which introduced the concept of header, footer and content canvas portlets along with “pluggable navigation.” For the first time, you could code your navigation against a supported and documented API and bundle it into a separate DLL or JAR file. When upgrades came along, you simply installed the new code and everything in your old DLL or JAR just worked. The only problem was that writing a pluggable navigation was really hard.

So, in ALUI G6 (the current version), you can easily make a navigation using a remote portlet and few lines of HTML, CSS along with a few handy XML tags. However, the old pluggable navigation model is still in the product, which begs the question: how do I know what form of navigation to use (native or remote)?

A lot of times you’ll hear me say, “it depends” i.e. it depends on your goals or it depends on your architecture. But, in this case, with 100% certainty, I can say that you want to go with remote navigation. Why? Because it’s about 1000 times easier to code, maintain and deploy, you can change it on the fly and in a breeze, you can include Javascript and CSS just like you would in a normal web page, you don’t have to work with confusing HTMLElement classes, you don’t have to know Java or C# . . . need I say more?

If you’re not sold yet on the concept of remote, XML tag based navigation over native pluggable navigation, consider the following example. Say I want to get all the mandatory with tab communities and display them in an unordered list.

Here’s the native code for that:

CListURLMediator mediator = new CListURLMediator(m_asOwner,
HTMLList ul = new HTMLList(1);
while (mediator.Next()) {
  HTMLListItem li = new HTMLListItem();
return ul;

And here’s the remote code:

<ul xmlns:pt='http://www.plumtree.com/xmlschemas/ptui/'>
  <pt:ptdata.mandtabcommsdata pt:id='mandtabcomms'/>
  <pt:logic.foreach pt:data='mandtabcomms' pt:var='c'>
    <li><pt:core.html pt:tag='a' href='$c.url'><pt:logic.value 

The code speaks for itself. (If you never have to learn what a CListURLMediator is, consider yourself lucky.) Not to mention that you have to worry about the NavType and deployment issues and that you have to restart the portal any time you make a change to your navigation code.

So, is remote, tag-based portlet navigation the solution to all your navigation needs? Not exactly. With pluggable navigation, you can control six navigation areas: the top bar, above the header, below the header, the left side, the right side and above the footer. It’s easy enough to suppress the top bar and replace the first three areas with your header portlet. Same goes for the footer. But what about the left and right sides? You can’t really replace those with portlets unless you use the two narrow columns, which leaves you with only a single portlet column for content.

So you’re in a pickle — you read this post and you’re now the world’s biggest remote navigation fan — but you can’t use them in left and right navigation. There is a solution. If you read this post in the newsgroups, you’ll see that it’s possible to write some code that will load a remote portlet into the left and/or right columns. (The only thing I would change about this code is make sure you put the portlet ID in a VarPack instead of hardcoding it.) Using this fairly simple approach, you can have your cake and eat it too.


Comments from BEA dev2dev are listed in date ascending order (oldest first)

  • were doing UI customization to modify the top nav section, but would like to move to remote portlet with tags instead for reasons you mention.
    If i understand correctly, we have to do this in header portlet. How do we enforce that that the same top nav is used across the portal if the community managers are able to change the tag code in the header portlet?

[email protected]

Posted by: sviau on July 9, 2006 at 7:04 AM

  • That’s a great question and I’m glad you asked it. First let me clear something up: community managers cannot and should not change the tag code. However, they can change which header portlets are being used for the communities they manage (and thus choose a whole new set of tags or no tags at all).

    Fortunately, there’s a easy way to prevent this from happening using community templates. There’s a check box on the “Header and Footer” page of the community template that says “Force Community to use Header and Footer from Experience Definition.” You’ll want to check this box. Then, as the portal administrator, you can mandate which community templates your community managers can use. Set it up so that your community managers are forced to use the community template with this box checked and you should be good to go.

    Posted by: bucchere on July 10, 2006 at 2:38 AM

  • Hopefully this is applicable here…I am trying to brand (or customize) the title bar of a portlet(s). I have determined how to change the text on the title bar (PortletResponse.setTitle) but cannot find nothing on changing colors or adding colors to the title bar. Can this even be done? Is there a CSS class somewhere or can it be done programmatically? Thanks for your assistance.

    Posted by: jayparker on January 2, 2007 at 12:28 PM

  • This should do the trick:
    .platportletHeaderBg {
     background-color: red;

    Posted by: bucchere on January 10, 2007 at 7:13 PM

  • is the remote code supported in 6.1 mp1? I attempted to run it and nothing is generated. Has mandtabcommsdata gone away? I notice it also is absent from the current edocs http://edocs.bea.com/alui/devdoc/docs60/Portlets/Adaptive_Portlets/Using_Adaptive_Tags/PlumtreeDevDoc_Portlets_Adaptive_Navigation.htm

    Posted by: geoffgarcia on October 2, 2007 at 11:26 AM