9.5. Preliminaries Part I: A Brief History of Portals and Portlets (Apologies to Professor Hawking)

Before we get into the code of this application, I want to provide a context for what is to come. The first piece of business is to talk about the idea of a portal.

A portal is a way to organize the UI of an application so that there are small, discrete "modules" that can be displayed on the screen. Generally, these modules, which are called portlets, are rectangular in nature. Each portlet can provide some piece of functionality, and the user usually has control over which portlets are on the screen.

For example, if you were to create a news portal site, you might have a portlet for world news, another portlet for local news, one for sports, and one for financial news. You might also have a portlet where discussions among users about news stories could be found. The user could selectively show or hide any of these portlets, and usually they can be collapsed instead of removed from the UI. Users can also add other portlets as they wish to the UI to have other pieces of functionality available to them.

Portlets in a portal can also usually be arranged by the user. The interface to rearranging them can vary, but one fairly typical approach is to allow users to drag the portlets around and drop them where they want them to be.

The benefit to a portal architecture is that users are in control. They decide, from a list of choices, the available portlets in this case, what they see on the page, and how it's organized. A portal is an aggregation of different pieces of functionality encapsulated within the portlets it provides, so another advantage is that the user can have numerous, potentially very disparate sources of information in one consolidated view.

Portals are a popular choice for company intranet sites, personal information management (PIM) sites, and similar types of applications. In the Java world, there is a whole specification dedicated to the technology behind portals, and various vendors provide their own unique implementations of the specification with all sorts of value-added goodies such as cross-portlet authentication, preferences management, and out-of-the-box portlets for all sorts of things.

However, in the case of Finance Master, we don't have a full spec to support us. Instead, we have to go it alone. Thankfully, the Ext JS team created an example, one you can find on the Ext JS site that provides the basics of a portal application in JavaScript. Utilizing the extension code they wrote for that example, we can provide the same sort of interface design to Finance Master without much work at all.

One important consideration in portal creation, from a coding standpoint, is that since the portlets can be added and removed, expanded or collapsed, and arranged by the user, individual portlets have to be truly independent. They can't make assumptions about other portlets because it's easy to imagine a function call to a portlet that was removed leading to a quick JavaScript error. Fortunately, there is a rather easy solution to this problem: the publish/subscribe model.