Four ALI IDKs at your Disposal — Fifth One on the Way?

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 ([email protected])

    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

  • Hi, Chris. We would love to have a Lotus Notes/Domino IDK available to us, as we have lots of “legacy” applications in Domino that we want to expose in ALUI, and an IDK would certainly help! Just my nickel’s worth… 🙂

    Posted by: kcepull on March 30, 2007 at 11:21 AM

  • Thanks for your comment. If you don’t mind my asking, would you be willing to pay for such a thing or is it only a nice-to-have that you would download and use if it were opensource, but not pay for it if it were a commercial product?

    Posted by: bucchere on March 31, 2007 at 6:07 PM

.NET Meet Java (and vice versa)

Here are my notes from this session, which, BTW, is the best talk I’ve seen today. (The best yesterday was Eric Whitley’s.)

Interesting stat: 80% of the Fortune 500 use .NET.

Microsoft is committed to a January 2007 release of Excel Services for the Web, which has interesting implications for ALUI. Perhaps there’s an opportunity here for building ALUI/MS Excel integration the right way. Finally.

The .NET Application Accelerator is coming in a matter of weeks. It will expose any .NET application as a WSRP service that can be consumed by ALI or WLP.

Searching Intrinsic Properties in .NET

I won’t waste your time with any introductory drivel — if you want that, you can read the other post. Let’s get right into the code.

Plumtree.Remote.PRC.Search.IntrinsicPortalField.cs:

using System;
using com.plumtree.remote.prc.search.xp;
using com.plumtree.remote.prc.search;

namespace Plumtree.Remote.PRC.Search
{
 public class IntrinsicPortalField : Field
 {
  private IntrinsicPortalField(IntrinsicXPPortalField xpField) : base(xpField)
  {
   ;
  }

  public static readonly IntrinsicPortalField EMAIL_ADDRESS = new
   IntrinsicPortalField(IntrinsicXPPortalField.forID(26));
 }
}

com.plumtree.remote.prc.search.xp.IntrinsicXPPortalField.cs:

using System;

namespace com.plumtree.remote.prc.search.xp
{
 public class IntrinsicXPPortalField : XPField
 {
  private IntrinsicXPPortalField(String name, bool isSearchable, bool isRetrievable) :
   base(name, isSearchable, isRetrievable)
  {
   ;
  }

  public static IntrinsicXPPortalField forID(int propertyId)
  {
   return new IntrinsicXPPortalField("ptportal.propertyid." + propertyId, true, true);
  }
 }
}

Enjoy!

Everyone likes a friendly URL

As part of our BEA World strategy for this year, we’re revamping our corporate web site, http://www.bdg-online.com. You should expect an unveiling in the upcoming weeks.

While there will be some revised and some additional content, this is primarily an infrastructure upgrade, including moving to more powerful virtual hosts and upgrading the backend from ASP to ASP.NET (yes, I know, it’s about time).

One of things that really bugs me about ASP and ASP.NET is the failure to include built-in support for friendly URLs. By friendly I mean something that doesn’t end in .asp, .htm, .aspx or some other extension and naturally also doesn’t have a querystring (?foo=bar&boo=moo . . . etc.). For example, http://www.bdg-online.com/customers is a lot more friendly than http://www.bdg-online.com/customers.asp and definitely more friendly than something like http://www.bdg-online.com/content.aspx?p=/customers.

Java provides a nice facility for this in the form of servlet mappings. Since a lot of people are using MVC these days, you are probably going to set up servlet mappings anyway. Here’s an example from a sample web.xml file:

<servlet>
 <servlet-name>customers</servlet-name>
 <servlet-class>com.bdg-online.www.Customers</servlet-class>
</servlet>

<servlet-mapping>
 <servlet-name>customers</servlet-name>
 <url-pattern>/customers/*</url-pattern>
</servlet-mapping>

But what about ASP or ASP.NET? No one cares about ASP any more, so I didn’t bother to research that. But for .NET, I came up with a simple and elegant solution to the friendly URL problem. All you need to do is add the following code (or something like it) to your Global.asax.cs file:

protected void Application_BeginRequest(Object sender, EventArgs e)
{
 if (!Request.RawUrl.EndsWith("htm") &&
     !Request.RawUrl.EndsWith("css") &&
     !Request.RawUrl.EndsWith("ico") &&
     !Request.RawUrl.EndsWith("jpg") &&
     !Request.RawUrl.EndsWith("js") &&
     !Request.RawUrl.EndsWith("gif"))
 {
   if ("".Equals(Request.RawUrl) || "/".Equals(Request.RawUrl))
   {
     Context.Server.Transfer("default.aspx");
   }
   else
   {
     Context.Server.Transfer(Request.RawUrl + ".aspx");
   }
 }
}

You’ll note that I forward requests to the corresponding aspx page, as long as the request isn’t for static content (images, css, etc.).

Of course you also need to do two things:

  1. Configure an .aspx page for every friendly URL you want resolved
  2. Add a wildcard mapping in IIS for * (files without extensions) to the asp.net ISAPI filter

The process for #2 is a little involved. It’s also different for IIS 5 (XP) and IIS 6 (2003). I don’t feel like posting screen shots right now, but if anyone wants to give this a trial run and can’t figure out how to do #2, just e-mail me and I’ll walk you through it.

I just came up with this a couple of hours ago and I haven’t put it through much testing, so YMMV.