This section presents the main concepts used by Jetspeed portal layout system as well as the document object model on some fundamental aspects of the portal layout API.
The reader is assumed to have familiarity with the Turbine 2 principles especially those related to the page real estate organization, ie layout, navigation and screen.
Jetspeed manages its layout with 4 main components:
A Portlet is the basic layout component responsible for rendering
its content, wherever it's placed within the portal page.
A PortletController is responsible for laying out a set of
Portlet objects on a page, using layout constraints and hints.
A PortletSet is a specific Portlet that acts as a container,
holding several portlets to be displayed on the same page. A PortletSet
instance is always associated with a PortletController that governs its
actual layout strategy.
A PortletControl is a specific Portlet that is responsible for
decorating another Portlet. These controls are mainly used to provide titlebars
around objects and control the
A typical portal page would combine all of these elements to render the full portal within a single Turbine screen area, as shown in the following schema:
This example also shows how the Jetspeed panes are handled by specialized controllers and
controls, respectively PanedPortletController and PanedPortletControl.
The main difference between a regular PortletController and a
PanedPortletController is that the latter does not render all its managed portlets
at the same time on the page and thus needs to provide methods to "browse" through the different
hidden portlets. A PanedPortletControl is a control that knows that its content
may not be fully visible at a given time and thus provides navigation links to display
the none visible elements.
The Layout API which is the foundation of the portal page rendering in Jetspeed is loosely based on AWT design:
There's no real equivalent to the PortletControl class, which mostly acts as a
managing proxy for an inner Portlet or PortletSet.
Note that in this API, the Portlet class is used as a simple graphical widget
and thus although it's possible to overload its behavior to also have a servlet-like
component lifecycle model, it's best to keep its subclass operations as simple as possible
and implement expensive business operations in other classes (Turbine tools, EJBs, etc...).
The portal page is rendered by the portal engine using a document object model tree of portlet
objects. This DOM tree is typically created by the PortalToolkit service from a
static PSML page description resource.
The complete page rendering process is triggered by calling the getContent method
on the root portlet object. The following sequences describe the standard layout sequence using
the default Velocity based Turbine setup.