Model SPI overview

 

+

Search Tips   |   Advanced Search

 

Models provide information needed by WebSphere Portal to perform tasks such as...

• content aggregation
• building navigation to browse the aggregated content

The information that is aggregated is represented through models that can be accessed programmatically using the Model SPI (read-only).

The information of a model is usually persistent (stored in a data base) but can also be transient (computed and stored only in memory). Models can be represented using...

• tree structure (nodes have a parent-child relationship)
• list structure
• selection structure (a selected element in a tree structure)

The following models can be obtained using the Model SPI:

Content Model

Topology in which the content is structured. The content model is a tree structure composed of content nodes. Types of content nodes...

• pages
• labels
• internal URLs
• external URLs

Navigation Model

Topology of the navigation visible to a specific user, which is composed of navigation nodes. Navigation nodes are implied by the structure of the content model. A navigation node references content represented by content nodes.

Navigation Selection Model

Selected node in the navigation.

Content Meta Data Model

Provides access to meta data of nodes of the Content Model. The meta data are aggregated using the hierarchy that the content model exposes.

Language List

List of supported languages.

Layout Model

Layout of a page, which is composed of layout nodes. Layout nodes can be...

• Containers, which affect the layout of the page (rows and columns)
• Controls, which affect the content (portlets) of a page

Markup List

List of supported markup languages.

Skin List

List of skins.

Theme List

List of themes.

PortletModel, AdminPortletModel

Portlets and their associated configuration data.

 

Example: Creating a specific model from source information

The interfaces of the public object model provide read-only access to resources. Manipulation is possible only through the user interface.

The models as well as their elements are all described through interfaces residing in the package com.ibm.portal and its sub packages.

The more common interfaces are located higher in the package hierarchy. For example, Identifiable, an interface present on almost all resources, is located directly under com.ibm.portal.

 

Model scope

The models present information based on access control. This means that models are scoped to a specific user, and requests to retrieve model information return only the resources to which the user has access.

The concept of virtual portals scopes some models to the virtual portal a user operates in. At the moment this applies to...

• content model
• navigation model
• navigation selection model

These models scope their resources to the virtual portal a user operates in.

 

The main package, com.ibm.portal

The com.ibm.portal package holds interfaces commonly used throughout the object model. This document will describe important interfaces and classes found in the object model, not each single one.

Most resources carry an identifier. This can be used to address or locate them. This identifier is defined with the interface Identifiable which allows retrieving the ID of an element. An object ID uniquely identifies an element in an installation - and beyond (the ID is also called GUID - globally unique ID). An object ID can optionally have a unique name assigned (a name that can only exist once per installation) to make things easier when addressing special elements.

Note that using toString on object IDs is generally discouraged - a human readable representation is returned that cannot simply be parsed back into an ObjectID object. For conversion between an ObjectID object and its string representation, the Identification interface is used...

package com.ibm.portal.identification

A common operation is to search for resources having a specific object ID. To do this in a general way, the concept of a Locator is introduced: A locator is usually provided by a model and allows searching for elements of the model in specific ways. To obtain such a locator object, you have to use the getLocator method of an object that implements the LocatorProvider interface.

The generic locator interface allows you to locate a resource by its object ID (findByObjectID) or by its unique name (findByUniqueName). Some models provide specialized locators that extend the generic locator to provide additional search functionality such as search by title or some other criterion.

On a generic level, models are either lists or trees. Therefore a TreeModel and a ListModel interface exist in the main package. In a tree model, it is possible to do the following tasks.

• Obtain the root node of a tree model (getRoot)

• Query the children of a node of the model (hasChildren)

• Obtain the children of a node of the model (getChildren)

• Obtain the parent of a node of the model (getParent)

With these methods it is possible to explore a tree model. The input arguments representing nodes of the model must have been obtained from the model itself.

In combination with the locator concept discussed above, a tree model becomes a searchable tree model: SearchableTreeModel is a tree model that also extends from LocatorProvider.

Some models also take on the form of a list, for example the list of markups or the list of languages supported by WebSphere Portal. The generic way to directly access the elements of the list is through the iterator provided by it (iterator method). When a method returns a list model, it will use the interface ListModel; however in some situations it may also return a PagedListModel, which extends from ListModel and additionally provides a paged iterator. This allows obtaining the elements of the list model in chunks, which can be better performing than to obtain each element individually.

List models become searchable the same way tree models do: SearchableListModel is a list model that also extends from LocatorProvider.

A widespread interface on elements of models is Localized. This interface provides a title and description of an element. Title and description are properties that are locale-dependant. To obtain a title or description call getTitle(Locale) or getDescription(Locale) respectively.

Please note the important fact that an element will only return a title or description if such information exists in the exact locale that is passed in to the methods mentioned. This means that there is no fallback implemented inside of these methods. A suitable fallback mechanism must be employed by invokers of the methods of Localized, or the default provided by LocalizedStringResolver (see package com.ibm.portal.model) can be used.

 

See also

• Sub packages of the Model SPI
• Obtaining a model from the portal
• Obtaining the object ID for a page or portlet
• Model SPI samples
• Remote Model SPI REST service

 

Parent topic

Developing portlets