Sub packages of the Model SPI

 

+

Search Tips   |   Advanced Search

 

The Model SPI includes the following subpackages.

 

The sub package com.ibm.portal.admin

WebSphere Portal provides several list models that contain information on installed resources, such as...

For each of these, a specific ListModel exists that provides information on these resources. This package defines several list models:

LanguageList Languages that are supported by the portal
MarkupList Markups that the portal generally supports. From these, a resource may only support a selection
SkinList Skins that are installed for the portal.
ThemeList Themes that are installed for the portal.

 

The sub package com.ibm.portal.content

Elements of this package define how content is represented in the portal. The two main models of this package are the ContentModel and the LayoutModel. The content model defines a tree structure for content elements, such as pages and labels. It is used to group these logically.

Note that the topology of the content model currently dictates the topology of the navigation model. Theoretically, the topologies of content model and navigation model are allowed to diverge.

Currently, the elements of the content model can be pages, labels or URLs. For each type a specific ContentNode interface exists: ContentPage, ContentLabel and ContentURL. Each content node has different information associated with it.

Each content node can provide the type of content node it represents; if this type is ContentNodeType.PAGE, a model exists that represents the layout of that page. It can be obtained with the getLayoutModel method of the content model. The layout model holds LayoutNode elements that describe the layout and contents of the page. Each layout node can return metrics in form of the LayoutMetrics interface. It can describe attributes of the node such as width or orientation (horizontal/vertical).

The elements of the layout model are either LayoutContainers that define rows and columns or LayoutControls, which represent portlets. This information is used when a page is rendered.

The following figure shows how page layout information and page content is represented.

The figure depicts a page with three portlets. The surrounding vertical and horizontal containers define the layout while the controls hold the portlets that provide the actual content presented to the user.

Content nodes can provide meta data through the com.ibm.portal.MetaDataProvider interface. Meta data can be used to associate arbitrary information with a content node. The content meta data model provides a view on meta data of the nodes in the content model. It aggregates the meta data of the individual nodes into one meta data object by using the hierarchy of the nodes as described in the content model.

The following figure shows the relationship between the individual meta data that are exposed by content nodes and the aggregated view that the content meta data model provides:

The meta data of individual content nodes are exposed in XML Access scripts using the <parameter> tag.

 

The sub package com.ibm.portal.identification

This package holds the Identification interface which allows the conversion between ObjectID objects and their string representation. This is required where an object ID is to be passed as a parameter that can only be a String (for inclusion into URLs, for example). An implementation of this interface can be retrieved by using a JNDI lookup, as in the following example. 

 try
{
   Context ctx = new InitialContext();
   Name ctxName = new CompositeName("portal:services/Identification");    
   Identification identification = (Identification) ctx.lookup(ctxName);    
   String serializedOID = identification.serialize(aOID);
 
      ...

   ObjectID anotherOID = identification.deserialize(serializedOID);
}
catch (SerializationException sx)
{
   // some error handling code here
}
catch (NamingException nx)
{
   // some error handling code here
}

 

The sub package com.ibm.portal.navigation

This package defines the navigation model (NavigationModel) which represents a view on content model used for navigation. As described in section "The sub package com.ibm.portal.content", the topology of the navigation model currently corresponds with that of the content model - each node in the content model has an equivalent navigation node at the same hierarchical level.

The elements of the navigation model are NavigationNodes. Each such node can reference a ContentNode. The navigation nodes have a title that is provided through the Localized interface. The following figure shows the connection between the navigation model and the content model.

Navigation model Content model

When a user is navigating through the portal, the currently selected navigation node is important to render the current page. The NavigationSelectionModel reflects the current selection. It represents a list that defines a path through the navigation model.

Navigation model Navigation selection model

The last node of this path is always the currently selected navigation node, and its referenced content node represents what is aggregated for the user to see (normally a page represented through a ContentPage object).

 

The sub package com.ibm.portal.portletmodel

The PortletModel represents portlets and their configuration data in the portal. It contains the following elements:

WebApplication

represents a deployed WAR file in the portal.

Portlet

the programmer in the deployment descriptor of a portlet web application. Each portlet web application contains one or more portlets.

PortletDefinition

represents administrator configuration for a portlet. Multiple portlet definitions can be associated with the same portlet, so that the same portlet code can be invoked with different administrative settings. The administrative UI of the portal allows to create new portlet definitions as copies of existing ones.

PortletEntity

represents end-user configuration for a portlet. It is normally created by placing a portlet definition on a page; the same portlet definition can be added to multiple pages, resulting in multiple portlet entities. There can be two levels of end-user configuration (shared and personalized configuration) that are stored in the form of separate portlet entities.

PortletWindow

represents a particular view on a portlet. It normally corresponds to a LayoutControl in the layout model. The same PortletWindow can be associated with different PorltetEntities for different users, if they have personalized the portlet independently.

 

Parent topic

Model SPI overview

 

Related concepts

Obtaining a model from the portal
Remote Model SPI REST service

 

Related reference

Model SPI samples

 

Related information

Obtaining the object ID for a page or portlet