Seeking WebSphere Portal Server advice

I am currently involved in a huge public sector Web portal project that will be based on IBM's WebSphere Portal Server. One of my responsibilities in the project is to provide guidelines and recommendations for all front-end code, including HTML, CSS, JavaScript, and RSS.

Not knowing a whole lot about WebSphere Portal Server I am slightly worried that the software will make it difficult (or even impossible) to achieve and maintain the high quality standards I would like all front-end code to meet. By high quality front-end code I mean lean, valid, semantic, and accessible HTML, CSS, and JavaScript.

Learning more about the possibilities of customising the code it outputs is on my agenda, but I'm very interested in other people's impressions from doing front-end work in projects based on WebSphere Portal Server. More specifically I would like to find answers to these questions:

  • Does it allow full control of the code sent to user agents?
  • How difficult is it to edit the preinstalled themes and skins?
  • Is editing themes and skins advisable or will doing so lead to maintenance problems down the road?

During a one day workshop on WebSphere that I attended I noticed that the default markup used is far from up-to-date. It didn't seem quite as bad as that produced by most Microsoft products, but I did not like what I saw. If the end result is going to adhere to the Swedish Guidelines for public sector websites, much of the default front-end code has to be heavily modified.

After seeing the default code, the following quote from the Redpaper WebSphere Portal Best Practices was a little surprising:

A portal is an open, standards-based framework supporting a wide array of options across databases, directories, platforms, and security.

Perhaps the developer who created the default installation forgot to read up on standards-based markup. Either that, or "standards-based" is only referring to the back-end systems.

In 3.2.3 Markup generation in the same document I found the following encouraging words about the use of iframes:

We do not like to see iFrames on portal pages. Years ago, the main reason was that Netscape 4.x browsers did not support it, but we do not see these browsers frequently any more. More concerns are regarding security and the portal concept. iFrames are just browsers on their own. With an iFrame in your page, WebSphere Portal would not be in control of the iFrames content, which is converse to the concept and might lead to unexpected problems.

Good. Avoiding iframes will make it easier to keep the front-end code under control.

As noted by Johan Berndtsson (who is also involved in this project) in WebSphere Portal UI design (in Swedish), the document warns the developer of promising too much customisation:

Be careful what you agree to regarding customizing the portal theme. […] Understand that customizing a portal theme to match an exotic, elaborate, or complex Web site can be very time-consuming.

Yes, but is customising a theme to deliver valid, semantic, and accessible markup exotic, elaborate, or complex? I hope not.

Any tips, suggestions, or pointers to good documentation are very welcome.

Posted on December 6, 2006 in Content Management