BEA Portal afterthoughts

I'm just about to complete a project using BEA portal and I found that this is a good time to reflect over the experience so far. This post isn't a technical consideration of the BEA Portal product. I've haven't worked with any other portal products and I also only worked on this project a few months. But this might be valuable for those getting started with BEA Portal - avoiding some of the struggles that I've experienced.

Linking within Portal
The way the portal and portlets handles links on isn't straight forward. The reason is that portlet is supposed to be self contained - without assuming to much of the environment that surrounds it. For web developers being used to link from one part to a completely different part, this comes up regular as a pain doing portal/portlet development. dev2dev have written an article regarding URL handling in the portal. It's worth a read, but isn't as practical as I would like have it. I miss a 'best practice' guide when it comes to URLs in the portal.

The front page typically have quite a few links into other parts of the portal. News entries and other campaigns will typically link into certain parts of the portal. These elements isn't suppose to be reusable for other contexts, so if they assumes things about the portal, it's OK. The render tags are the ones to be used when you need this kind of linking. We used the render:pageurl tag for this kind of linking. Read the render tags documentation.

We had the need for a redirection service - which used a few parameters and then redirected to the correct place in the portal. This redirection got written as a JSP (yeah - it should have been a servlet...), but when you need to redirect to a resource in the portal, you must remember that when you are accessing the JSP directly (using the direct URL to the JSP), you must change to 'portal-linking'. You should look at the PostbackURL class and there also is a postbackURL tag.

Another issue with linking is the difference between development environment portal configuration, which is stored in a .portal file, and the production environment portal configuration which involves defining a portal and a desktop. The URLs for these environments aren't identical - so be aware if you are doing any linking hack.

Configuration & Datasync tool
Configuration of the portal, done in the Portal Admin tool, is annoyingly dependent on the Portal Admin tool GUI. According to this thread, it isn't a public API for scripting up the portal configuration. This is very annoying because every time you have to create a new desktop because of changes in the .portal file in development environment, you also have to go through the tedious steps of reenter the entitlement configuration. Hopefully will the core server focus on WebLogic Scripting Tool make portal configuration available through WLST.

When I first deployed the portal on the test server, I wasn't able to use the custom Unified User Profile that I had written. In the development environment, the UUP showed up without any problem, and on the test server all the user interface logic dependent on this custom UUP worked, but the portal admin wouldn't display the UUP as available. So you have to use the Datasync tool to bootstrap configuration for this to be available in the portal admin tool. This is just plain weird. I haven't used this tool for anything else which also means that I don't see the big benefit of having it. Anyway - unnecessary complex...

Taglibraries
There are quite a few tag libraries available on a portal project within BEA Workshop. The ones with good tool support is, netui tags. I must say that you really feel the difference between the workshop framework (which is the Beehive project) and the rest of the portal tags. Example on this is that netui tags would store the result of a tag in an resultId attribute if available. This result would be put in pageContext for retrieval later in the JSP. The portal tags often doesn't include similar functionality and when they do - the attribute certainly isn't called resultId. This makes the tag libraries very inconsistent.

Some of the netui tags shouldn't be used in a portal setting - for instance in the linking area. I think workshop should see that this is a portal project and then 'promote' typical portal aware tags and possibly hide away tags that isn't supposed to be used in a portal setting.

There is also a mix of portal utility tags (notNull, isNull etc), struts tags and netui tags. I think that BEA should go the Java Standard Tag Library (JSTL) way instead of this collection of tags . Where some of them do the same thing.

To sum up, BEA needs to clean up the tag library usage and give the developers some help in choosing the correct tags....

Caching
When you are working with portlets, Workshop present the portlets properties. Among these properties are caching settings. We utilized this cache properties because there are many pages which are shared among all users. Typically open pages presenting product information, prices etc. Then this article got posted on dev2dev and we realized that the caching we had done weren't doing us any good because portlet caching is on user session level. So we were actually only using more resources - without getting any major benefits. I miss the operand's to say to a portlet that this information should be cached on a application level - no matter what user that sees this portlet.

Custom authentication provider
The customer had a need for a custom authentication provider. When you develop a custom authentication provider there are a collection of interfaces and some of them have to be implemented others are considered optional. The initial authentication provider only implemented the minimum set of interfaces that had to be implemented. This didn't work when using the UserLoginControl. After some investigation I found that the portal actually uses one of the optional interfaces called UserReader, because it uses the method boolean userExists(String username). So I implemented both the UserReader and GroupReader interface in my authentication provider. I still don't get the custom authentication provider's groups up in the portal admin tool user interface when trying to create entitlements, but this haven't been critical since I've used Global Roles defined in the realm of the server instead.

Custom Unified User Profile
Developing a custom Unified User Profile (UUP) is actually just to create a stateless session bean. Doing the development wasn't a problem, but configuring the UUP with P13n had too many manual steps for my taste. You had to extract the deployment descriptors for the existing p13n_ejb.jar file, add reference to the custom UUP and then update the p13n_ejb.jar file. I recommend using JRockIt when working with these jar files because JRockIt jar binary support the notion of updating a file within an existing jar. Sun's jar utility doesn't. BEA should provide tools support for doing this. Either command line or through Workshop.

I also had a few points about layout and usage of CSS, but I leave it for now...