As most of you already know, there are four IDKs out there in IDK-land. To take a step back, if you're really new to ALUI (formerly Plumtree) development, you can read about how ALUI handles portlets and how an IDK helps you write portlets. So, back to the four IDKs. They are all freely-downloadable from BEA -- I've included links here:
*These two IDKs were written by developers at bdg and then released to the open source community on dev2dev's CodeShare.
edocs warns you in boldface type: always use the IDK. That's sound advice, given that the IDK API isolates you, as a portlet developer, from changes to the underlying protocol that ALUI uses to communicate between the portal and portlets (CSP). However, what if you're not writing a portlet in Java, .NET, Ruby or PHP? As an aside, once upon a time, there were Perl and ColdFusion GDKs (predecessor to the EDK/IDK), but these development kits are no longer maintained by anyone, although I know for a fact that the ColdFusion GDK is still in use by an ALUI customer because it came up during a sales call!
So, back to my "what if" question: how can you write a portlet without an IDK? It's actually not too hard if you're just getting information from the portal. However, it gets challenging when you start setting preferences and then it starts to get really painful when you start dealing with Unicode issues, encrypted settings and some of the other really hairy stuff. So that's why edocs implores you to use an IDK, when one is available.
If you do go down the road of writing a portlet in a language where an IDK isn't available, I highly recommend that you at least abstract out your CSP calls such that they're isolated from the rest of your portlet code. While you're at it, you might as well follow the same API that BEA uses; in other words, write your own IDK (or at least the parts of it that you need to get your portlet done). To get you started, here's how BEA probably implemented one of the IDK methods in Java:
public AggregationMode getAggregationMode() {
if (!request.isGatewayed()) {
throw new NotGatewayedException("Request not gatewayed.");
}
if (request.getHeader("CSP-Aggregation-Mode").equals("Multiple"))
return AggregationMode.Multiple;
} else {
return AggregationMode.Single;
}
}
So, go forth and write your own IDK. Or, preferably, ask a bdg-er to write one for you!
On a related note, one of our customers recently asked us to build an IDK for Lotus Notes/Domino in LotusScript. We're trying to figure out if other people might be interested in this IDK so that we can decide if we're going to open source it or do it as a consulting project (or some hybrid of the two). If you are interested in LN/Domino development for ALUI, let us know by commenting on this blog. I always love hearing feedback from users of the PHP and Ruby IDKs as well.
Comments
Comments are listed in date ascending order (oldest first)
- Hi Chris. We have a couple of remote portlets on web servers running Perl so I looked around for awhile for the original Perl IDK but couldn't locate it, so I've written a Perl module that supports the methods provided by IPortletRequest. They're read-only methods but are really all we needed access to. man-page is here...
http://webdev.co.nz/Perl/IPortletRequest.txt Is this worth placing in codeshare do you reckon? I don't see a lot of action in the forums concerning Perl use.Dean Stringer (deans@waikato.ac.nz)
Posted by: deeknow on March 22, 2007 at 2:00 PM
- Hello Dean! The original Perl GDK was written so long ago that I'm not sure how much good it would do. It was based on CSP 1.0 and it followed the old GSServices API rather than the new com.plumtree.remote.portlet API.
I'm pretty stoked to find out that someone else has written at least part of an IDK -- that's impressive. Do I think it's worth posting to CodeShare? I haven't heard much talk about ALUI and Perl, but I guess it can't hurt.
Posted by: bucchere on March 22, 2007 at 5:03 PM
