Our relationship with BEA + BEAWorld 2006

I often get asked the question: what’s your relationship with BEA?

Without lapsing into buzzword bingo (e.g. synergy), let me just say this: bdg is a BEA “Select Services Partner.” We work on our own or team up with BEA sales and service folks (and sometimes other system integrators as well) to deliver ALUI solutions to our joint customers. Recently, our partner profile was approved by BEA for publication on their web site, where you can get the scoop on what we do here at bdg.

* * *

Considering all the fun we had at last year’s Odyssey, we’re planning on making a big splash at this year’s BEAWorld, which will feature a “Portal Pavilion” to cater to all the old Plumtree customers, partners and fans.

I can’t reveal too much about our plans just yet, but we’re putting out a call to our customers for speaking opportunities and gearing up to defend our “Booth of Pain” title (should we be called upon to do so). Also, if you plan to attend BEAWorld 2006, be sure to stop by the bdg booth to pick up some goodies . . . last year it was mousepads, but this year we’re thinking along the lines of something far less pragmatic. I’ll leave it at that. . . .

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!

Announcing my new dev2dev blog

I’m very pleased to announce that I’ve been selected by BEA to be one of their featured bloggers on dev2dev, BEA’s product community site for developers by developers. You can read my dev2dev blog for all the Plumtree/ALUI tips that you’re used to finding here, but continue to check this space for news about bdg.

Also, stay tuned for a new Plumtree/ALUI podcast . . . coming soon!

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

Cracking open ISO files

I’ve been doing a lot of installing and re-imaging lately 🙁 and I’ve had to work with ISO files quite a bit. I haven’t found any Windows freeware that writes ISO files to CDs that actually work. However, I did discover that WinRAR has built-in support for extracting ISO files onto your hard drive.

It won’t, however, help you burn an ISO to a CDR, but hopefully with this info you might not have to!

(By the way, Mac OSX has native support for burning ISOs to CDs built into the operating system.)