10x More Productive Blog!

It seems that a very significant portion of enterprise development involves various portal solutions. Even if certain applications will not directly benefit from a portal interface, corporations would like to standardize on a presentation layer that can be later integrated easily into an intranet or internet portal. Although portal development is certainly similar to normal Web development, certain portal-specific pitfalls could make the developers lives unneccessarily difficult. This collection of tips will help you to avoid these pitfalls, and hopefully will enable you to recognize the differences between a Portal-based and a simple Web front-end based application development.

This article will focus on the WebLogic Platform, and the WebLogic Portal (version 8.1), however my experience is that developers will face similar problems and challenges using other portal platforms.

Navigation elements in a typical Web application include various main menus, submenus, popup menus, shortcuts, and crumb trail links. There are many good pre-built packages for handling these elements in a Web application. On the server side, there are many packages to handle navigation, for example the Struts-menu tag library if you're building a Struts application. If you decide to build the server-side components yourself, on the client-side various cross-browser compatible DHTML menu builders will help you to render a functional and attractive navigation panel. DHTML Menu is a popular example of such a package. So if you're developing a typical Web application, you're pretty much spoiled with the number of versatile components to suit your users' needs.

Portal users typically expect a menu which is just as responsive, well-designed, and good looking as a Web application's menu; however developers must overcome some additional problems. Because the menu is a visual element, the rendering code is part of the Portal's "skin". The rendering of the menu, and the data about the items presented in the menu is driven by the Portal framework. In a typical WebLogic Portal application, the site structure is defined using the "Books And Pages" concept. The Portal administrator, and even the portal user may restructure the site, so it's not possible to create a static menu, or to cheat and render the menu and navigation elements in a simple way from the Portlet JSPs. There are various components which will utilize the framework to render the structure from the Books and Pages. BEA provides a pre-configured set of components to render a horizontal menu (either a single-level menu, or a multi-level menu), represented as tabs on the Web page. Review the following file to see how the HTML output for the menu is rendered by the framework:

"c:\bea\weblogic81\samples\portal\portalApp\tutorial\
  framework\skeletons\default\singlelevelmenu.jsp"

Probably the biggest cause of developer suffering is when the Portal framework and general Portal concepts are misunderstood by the designer of the application. Because of the similarity to UI frameworks, the designers may think that Portlets are analogous to GUI windows, or even worse, they will simply think that a Portlet is a replacement for the <table border="1"> HTML element. Indeed, the borders segmenting the various screen elements give us a clue about how to segment the screen into Portlets. But overdoing this, and cutting up pages unneccessarily may cause exteme difficulties and they will not provide any benefit at all. In WebLogic 8.1, there are very convenient ways to communicate between Portlets. There are mechanisms which will allow one Portlet to subscribe to another Portlet's events. However, this is far from the event handling mechanisms of a complex GUI application. A Portal framework is not a replacement or a superset of a windowing toolkit.

I'd like to really emphasize this: if certain elements and boxes on the screen belong together, will be only displayed together, and there's no reason to allow the user to switch off certain elements, then they should be contained within one Portlet. Even if they have borders within the Portlet! These elements don't have to be in the same JSP file, and they can be shared between Portlets, by using simple JSP include mechanisms. The sharing of context, event model, and state between the elements will make it much easier than creating complex hacks on synchronizing 2-3-4 portlets on a single Portal page.

WebLogic Portal 8.1 is in my opinion the most full-featured Portal product. It gives a lot of flexibility for the application developers to create complex enterprise applications on the platform. For the Web designer, instead of just providing simple, CSS-based hooks on customizing the look and feel of the Portal application, it provides a very flexible architecture to play with. The price for the flexibility is of course complexity.

In a typical Web development team, most of the look and feel related issues, style sheets, graphical elements are designed by one or more designers, who may not have extensive Java/JSP skills. For a Portal project, this will not be enough. A developer, who is fluent in JSP and in the Portal Framework, will need to assist the designer. If the design of the Portal is not a significant issue, and the stakeholders of the project are more interested in the functionality, then a designer may get the job done by tweaking the default theme/skin/look-and-feel files for the application, without really understanding its architecture. However, I've never been in such a project when the design was not one of the key interests for the business users...

My suggestion for Portal Project Managers is to allocate a significantly bigger time period for the look and feel than on a simple Web project, and to quickly start to do prototypes for the customer - but only do the prototypes using the Portal framework! It could be risky to do the UI and look and feel prototypes without knowing how it will be implemented using the framework.

Even though from the developer's perspective many complex portal applications look like rich clients, with complex PageFlows, and portlet interactions, users view the resulting portals as just another web page. They will try to bookmark Step no. 5 of a "checkout order" wizard, and when they return, they will expect their half-done order process to be resumed, and they will still use the Back button, even if they've been navigating through many of your portlets, and expect that the result will still make sense.

Unless you're one of the extremely lucky intranet developers who are still allowed to disable the browser back button, and to redirect to the portal start page for any bookmark, this will require serious effort. Before you embark on any development, prototype out the solutions for typical browser issues, and include the solutions in your architecture design document.

Portal applications typically use a wide range of abstraction layers, and are dependant on many layers of application code.

Figure 1. Framework layers

Any defect you have in your application will finally materialize in your portal layer, in the form of unhandled exceptions, or functional issues. In order to minimize the impact of these issues, the following strategies can be utilized:

Many developers start to build the application by building portlets or JSPs first. This makes sense as the UI design prototypes can be utilize to kickstart development. However in my opinion Workshop and the automatic generation features work best if you start to build your application from the lowest layers first.

If you're serving your data from the database, design your schema first. Then you can generate most of your Rowset Controls from it. If you're accessing your persistent store from EJBs, then generate your beans first. If you're displaying information from Web Services, have your Web Service Controls generated first. If you're accessing XML documents, write your XSD schema first, then generate your XMLBeans classes, then create a custom Control, and write your methods returning the XMLObjects. If you sorted out your lowest layers, you can autogenerate your PageFlow skeletons, your FormBeans, and your portlets easily. You can then update them with the HTML code from the UI prototypes, but you will have all the type information, actions, etc., and you don't have to worry about how to pull together the logic for it.

If your HTML prototype is heavily using CSS, instead of HTML formatting and layout codes, you will have an easier time to separate the JSP content from the skin/skeleton portal elements as well.

If you follow these practices, you will have a better chance to deliver a real portal:

Let me know what other tips and tricks you've been using to build your Portal site!