In order to leverage the many extension points available for building upon Portal Server, an understanding of the underlying architecture is essential. This section describes the underlying data model for Portal Server, the domain layer that rests above this data model, and the Portal Server presentation layer/rendering pipeline. We begin with a look at the building blocks for Portal Server, found in WAF.
Baseline support for Portal Server can be found in three places within WAF:
PDL data model support can be found in WAF PDL area for portal in the following files:
Portal.pdl — This file extends the WAF resource object type, and includes a Boolean field that designates whether a Portal is a template, as well as a two way association that joins a Portal ID column to a set of [0..n] portlets.
Portlet.pdl — This file includes two object type descriptions: One for PortletType and one for Portlet. PortletType includes a String field called profile, that describes whether a particular PortletType prefers to be rendered with a wide profile or a narrow profile. Portal Server uses this field as a guideline, but allows it to be overridden via the configuration UI at render time.
The Portlet object type definition extends the Resource object type - just as the Portal definition described above does. There are two interesting fields in the Portlet definition: cellNumber refers to the particular tile area in a rendered Portal that this Portlet should appear, and sortKey is used for ordering this Portlet with others in the same tile area.
Domain layer support for Portal Server can be found in the com.arsdigita.portal package and the com.arsdigita.portal.apportlet sub-package. The domain layer files provide the getter/setter methods that the persistence layer maps to columns in the appropriate database tables. The domain layer files on which Portal Server relies are:
com.arsdigita.portal.Portal — This is the principle domain class for a Portal instance. In addition to instance methods, this class also contains some static convenience methods that are useful to developers.
com.arsdigita.portal.PortalCollection — Class representing a domain collection of Portals.
com.arsdigita.portal.PortletType — Domain object for a particular type of portlet. A portlet type may have many instances; one per Portal, for example.
com.arsdigita.portal.PortletTypeCollection — This is a convenient class when a collection of portlet types is desired; for example, when a collection of all available portlets on the system is desired.
com.arsdigita.portal.Portlet — This class is a principle extension point for developers wishing to build their own portlets. Methods for extending this class are detailed in the Developing On Portal Server section of this document. The Portlet class is the domain class for portlets, and includes methods for getting and setting portlet properties.
com.arsdigita.portal.PortletCollection — A collection of Portlet instances.
com.arsdigita.portal.PortletSetup — This class is a convenience class for easily initializing a portlet. Setters are provided for portlet properties, and invoking the run method initializes the portlet into the system. An exception is thrown if any necessary fields are left unset.
com.arsdigita.portal.DefaultPortalModel — This Class is a bridge between the domain layer and the presentation layer. It provides a stateful backing to the Bebop portal classes described below. It implements the com.arsdigita.bebop.portal.PortalModel interface.
Presentation layer support for Portal Server is found in the com.arsdigita.bebop.portal package.
Note: There are two ways to build and render a Portal using the base classes found in this package: The first is the manner in which Portal Server implements, using the c.a.bebop.portal.Portal class as a model backed representation of a stateless Portlet collection. The other approach is to use c.a.bebop.portal.Portal as a container (the Portal Container approach), requiring the Portal to be completely rebuilt on each request. The advantage to this approach is that it allows for the use of stateful portals, but at a performance cost, as the Portal can not be cached across requests. Portal Server uses the first approach for several reasons, including performance. Some of the classes listed below are not used by Portal Server, but they are included in this list for the sake of completeness.
com.arsdigita.bebop.portal.Portal — This object is the presentation twin of the Portal domain class described above. Portal Server uses the first constructor that takes a PortalModelBuilder as an argument. When the Portal page is rendered, the generateXML method on this class is called with a Document Object Model (DOM) Element as an argument, and the PortalModelBuilder generates a new PortalModel. The PortalModel then returns an iterator of PortletRenderers to the Portal.generateXML method, and the XML output for each Portlet within the Portal is added to the DOM element by calling generateXML on each Portlet Renderer.
com.arsdigita.bebop.portal.PortalModel and com.arsdigita.bebop.portal.PortalModelBuilder — These two classes are the 'Model' in the Portal Server implementation of Model-View-Controller. They provide a dynamic representation of which Portlets are associated with a particular Portal for any given request.
com.arsdigita.bebop.portal. PortletConfigFormSection — When a PortletType is registered with the system (usually in an Initialization class), a form section can be associated with the PortletType that will be displayed when a new Portlet of that type is created. This form section can be used to store configuration data for the Portlet. Portlet configuration form sections should extend this base class. See the tutorials on Portlet creation for information on how to use this class.
com.arsdigita.bebop.portal.PortletRenderer — PortletRenderer is the interface description for rendering Portlets used with Portal Server.
com.arsdigita.bebop.portal.AbstractPortletRenderer This class implements the PortletRenderer interface, and provides a default XML wrapper for rendering portlets. This is the class to extend when implementing a Portlet renderer for a custom Portlet.
com.arsdigita.bebop.portal.Portlet — This class is not used by Portal Server.
com.arsdigita.bebop.portal.PortletSelectionModel — This class is not used by Portal Server.