Portal Anti-Patterns - Installment 1: Misuse of portlets

In my IT consulting projects I regularly get the chance to inspect enterprise web portals and to take a deep look at their software architecture. What my team and I find there is troublesome at best. And the problems are the same in nearly all the portals I checked, thus it’s sensible to call them anti-patterns. They present a great opportunity to learn from mistakes already made lest you don’t repeat them.

In this little series I’d like to share this experience with you. This time, my topic is the use (or rather misuse) of portlets.

Anti-Pattern: “Page Portlet”

Portlets are a great way of bringing modules to the user interface. They also offer possibilities of reuse while at the same time encapsulating logic and data. Therefore, as a best practice, a portal page is expected to consist of multiple portlets, a reasonable number being 3 to 8. Nevertheless, I often encounter the so-called “page portlet” syndrome: each page of the portal is made up of one single portlets (or sometimes two portlets, one of which only represents navigation of header or something similar.

"Page Portlet" Anti-Pattern

This spoils all the positive aspects of portlets. Above all, portlets of this size are often so specific to a certain use case, that reuse is not possible effectively. Furthermore, it prevents approaches like responsive design to work on portlet level – everything has to be implemented in the portlet and thus cannot be configured and controlled by the portal server.

A “page portlet” should only be used as an intermediary step, when an application has to be split up into multiple portlets but in the current release there was not enough time to accomplish that. Then, you could tentatively integrate the whole application as one portlet into one portal page – but certainly not as final solution.