Sous-modules de la SPI du modèle
Les sous-modules fournissent des informations sur les ressources installées, contiennent l'interface Identification et définissent le modèle de navigation ainsi que le contenu représenté dans le portail. Les sous-modules représentent également les portlets et leurs données de configuration dans le portail ainsi que les interconnexions entre les portlets.
Le modèle SPI inclut les sous-modules suivants.
- Sous-module com.ibm.portal.admin
- Sous-module com.ibm.portal.content
- Sous-module com.ibm.portal.identification
- Sous-module com.ibm.portal.navigation
- Sous-module com.ibm.portal.portletmodel
- Sous-module com.ibm.portal.wire
Voir Présentation de la SPI du modèle pour une description du module principal dans la SPI du modèle : com.ibm.portal.
Sous-module com.ibm.portal.admin
WebSphere Portal fournit plusieurs modèles de liste contenant des informations sur les ressources installées, telles que les langues, les marquages, les habillages et les thèmes pris en charge. Pour chacune de ces ressources une interface ListModel fournit des informations sur ces ressources. Ce module définit plusieurs modèles de liste :
- Modèle de liste Langue
- Modèle de liste Marquage
- Modèle de liste Habillage
- Modèle de liste Thème
- Modèle de classe d'unités
Chaque modèle de liste contient des éléments qui implémentent des interfaces correspondant à leur nom : le modèle de liste langue renferme des éléments de langue. Le modèle de liste de marquage comporte des éléments de marquage. Le modèle de liste d'habillage comporte des éléments d'habillage. Le modèle de liste de thème comporte des éléments de thème et le modèle de classe d'unité des éléments de classe d'unité.
La liste de langues contient toutes les langues prises en charge par le portail. MarkupList contient tous les marquages que le portail prend généralement en charge. A partir de ces modèles de liste il se peut qu'une ressource prenne en charge uniquement une sélection. SkinList et ThemeList contiennent les thèmes et les habillages installés pour le portail. DeviceClassModel contient les classes d'appareil que le portail prend généralement en charge.
Sous-module com.ibm.portal.content
Actuellement, les élémens du modèle de contenu peuvent être des pages, des libellés ou des URL. Il existe une interface ContentNode spécifique pour chaque type : ContentPage, ContentLabel et ContentURL. Différentes informations sont associées à chaque noeud de contenu.
Chaque noeud de contenu peut fournir le type de noeud de contenu qu'il représente ; si ce type est ContentNodeType.PAGE, il existe un modèle représentant la disposition de cette page. Il peut être obtenu à l'aide de la méthode getLayoutModel du modèle de contenu. Le modèle de présentation contient des éléments LayoutNode qui décrivent la disposition et le contenu de la page. Chaque noeud de mise en page peut renvoyer des unités de mesure dans l'interface de LayoutMetrics. Il peut décrire des attributs du noeud tels que la largeur ou l'orientation (horizontale/verticale).
Les éléments du modèle de mise en page sont des éléments LayoutContainers qui définissent des lignes ou des colonnes, ou des éléments LayoutControls, qui représentent des portlets. Ces informations sont utilisées lorsqu'une page est affichée.
L'illustration suivante indique comment des informations sur la disposition d'une page et le contenu d'une page sont représentés. Elle représente une page avec trois portlets. Les conteneurs verticaux et horizontaux environnants définissent la mise en page, alors que les contrôles contiennent les portlets qui fournissent le contenu réel présenté à l'utilisateur.

Les noeuds de contenu peuvent fournir des métadonnées via l'interface com.ibm.portal.MetaDataProvider. Ces métadonnées peuvent être utilisées pour associer des informations arbitraires à un noeud de contenu. Le modèle de métadonnées de contenu fournit une vue sur les métadonnées des noeuds dans le modèle de contenu. Les métadonnées des noeuds individuels sont agrégées dans un objet métadonnées à l'aide de la hiérarchie de noeuds, comme décrit dans le modèle de contenu.
La figure ci-dessous montre la relation entre les métadonnées affichées par noeud de contenu et la vue agrégée fournie par le modèle de métadonnées de contenu :

Les métadonnées des différents noeuds de contenu apparaissent dans les scripts XML Access à l'aide de la balise <parameter>.
Sous-module com.ibm.portal.identification
Ce module contient l'interface Identification qui permet la conversion entre les objets ObjectID et leur représentation sous forme de chaîne. Cette interface Identification est requise lorsqu'un ID objet doit être transmis comme paramètre uniquement sous forme de chaîne (pour l'inclusion dans des URL, par exemple). Vous pouvez récupérer une implémentation de cette interface à l'aide d'une recherche JNDI, comme indiqué dans l'exemple suivant.
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
}
Sous-module com.ibm.portal.portletmodel
- WebApplication
- Représente un fichier WAR déployé dans le portail.
- Portlet
- Programmeur dans le descripteur de déploiement d'une application Web de portlet. Chaque application web de portlet contient un ou plusieurs portlets.
- PortletDefinition
- Représente la configuration d'administrateur pour un portlet. Plusieurs définitions de portlet peuvent être associées au même portlet ce qui permet de démarrer le même code de portlet avec différents paramètres d'administration. L'interface utilisateur du portail permet de créer de nouvelles définitions de portlet comme copies de celles existantes.
- PortletEntity
- Représente une configuration utilisateur pour un portlet. Elle est normalement créée en plaçant une définition de portlet sur une page ; la même définition de portlet peut être ajoutée à plusieurs pages, générant des entités de portlet multiples. Il peut exister deux niveaux de configuration utilisateur (configuration partagée et configuration personnalisée) qui sont enregistrés sous la forme d'entités de portlet distinctes.
- PortletWindow
- Représente une vue particulière d'un portlet. Elle correspond normalement à un LayoutControl dans le modèle de présentation. Le même objet PortletWindow peut être associé à différents éléments PorltetEntities pour différents utilisateurs s'il personnalisent le portlet de manière indépendante.
- CommunicationEndpoint
- Représente un noeud final disponible pour la communication définie pour le portlet. Ces noeuds finaux peut être du type CommunicationSource ou CommunicationTarget et sont disponibles via le fournisseur CommunicationEndpointProvider. Ce fournisseur peut être extrait à l'aide de la méthode getEndpointProvider sur PortletDefinition. Pour les portlets JSR 286 qui ont été déployés pour la gestion des événements, PublishingEventDefinition[s] et ProcessingEventDefinition[s] représentent les événements qu'un portlet unique peut traiter ou publier suivant la procédure définie dans le fichier portlet.xml. PublishingEventDefinition correspond à CommunicationSource et ProcessingEventDefinition correspond à CommunicationTarget pour les portlets JSR 286.
Sous-module com.ibm.portal.wire
- Connexion
- Représente l'interconnexion entre un objet CommunicationSource de PortletDefinition d'un objet PortletWindow sur une page source et l'objet CommunicationTarget de PortletDefinition d'un objet PortletWindow sur une page cible. Des exemples d'interconnexion sont proposés ci-dessous :
- Entre un portlet coopératif JSR 168 avec une propriété de sortie et un portlet coopératif JSR 168 avec une action cible définie.
- Entre un portlet JSR 286 qui définit un événement de publication et un portlet JSR 286 qui définit un événement de traitement.

