Présentation du SPI modèle
Les modèles fournissent les informations requises par HCL pour exécuter des tâches telles que l'agrégation de contenu ou la conception de navigation pour explorer le contenu agrégé. Les informations agrégées sont représentées via des modèles accessibles par programme à l'aide de la SPI du modèle (en lecture seule). En général, les informations d'un modèle sont persistantes (stockées dans une base de données) mais peuvent également être provisoires (élaborées et stockées uniquement dans la mémoire). Les modèles peuvent être représentés à l'aide d'une structure arborescente (noeuds ayant une relation parent-enfant), d'une structure de liste ou d'une structure de sélection (un élément sélectionné dans une structure arborescente).
Les modèles suivants peuvent être obtenus à l'aide de la SPI du modèle :
- Modèle de contenu
- Décrit la topologie dans laquelle le contenu est structuré. Le modèle de contenu est une structure arborescente composée de noeuds de contenu. Les pages, les étiquettes, les URL internes et les URL externes sont des types de noeuds de contenu.
- Modèle de navigation
- Décrit la topologie de la navigation visible pour un utilisateur spécifique, qui se compose de noeuds de navigation. Les noeuds de navigation sont impliqués par la structure du modèle de contenu. Un noeud de navigation référence le contenu représenté par les noeuds de contenu.
- Modèle de sélection de navigation
- Décrit le noeud sélectionné dans la navigation.
- Modèle de métadonnées de contenu
- Permet d'accéder aux métadonnées des noeuds du modèle de contenu. Les métadonnées sont agrégées avec la hiérarchie que le modèle de contenu expose.
- Liste de langues
- Liste de langues prises en charge.
- Modèle de mise en page
- Décrit la présentation d'une page, qui se compose de noeuds de présentation. Les noeuds de disposition peuvent être des conteneurs, qui affectent la disposition de la page (lignes et colonnes), ou des contrôles, qui affectent le contenu (portlets) d'une page.
- Liste des marquages
- Liste de langages de balisage pris en charge.
- Liste des habillages
- Liste d'habillages.
- Liste des thèmes
- Liste de thèmes.
- PortletModel, AdminPortletModel
- Décrit les portlets et les données de configuration qui leur sont associées.
Le tableau ci-après montre comment un modèle est demandé pour une utilisation spécifique à partir de la source de modèle, ainsi que la cible de modèle qui est renvoyée.
| Source modèle | Le modèle spécifique est demandé à partir de la source et celle-ci renvoie le modèle spécifique. | Cible de modèle qui est renvoyée et filtrée pour une utilisation spécifique |
|---|---|---|
 |
 |
 |
Création d'un modèle spécifique à partir des informations concernant la source
Les interfaces du modèle d'objet public fournissent l'accès en lecture seule aux ressources. La manipulation est possible uniquement via la SPI du contrôleur .
Les modèles et leurs éléments sont tous décrits à travers les interfaces résidant dans le module com.ibm.portal et ses sous-modules. Les interfaces les plus courantes sont situées à un niveau supérieur dans la hiérarchie du module. Par exemple, Identifiable, une interface présente sur presque toutes les ressources, est située directement sous com.ibm.portal.
Portée de modèle
Les modèles présentent des informations en fonction du contrôle d'accès. Par conséquent, les modèles sont configurés pour un utilisateur spécifique et les demandes pour récupérer des informations de modèle renvoient uniquement les ressources auxquelles l'utilisateur a accès.
Le concept de portails virtuels permet de configurer certains modèles dans la portée du portail virtuel dans lequel un utilisateur travaille. Pour le moment, ce concept de configuration s'applique au modèle de contenu, au modèle de navigation et au modèle de sélection de navigation. Ces modèles configurent leurs ressources dans la portée du portail virtuel dans lequel un utilisateur travaille.
Module principal com.ibm.portal
Le module com.ibm.portal contient des interfaces généralement utilisées pour le modèle objet. Ce document décrit les interfaces et les classes importantes contenues dans le modèle d'objet. Il ne décrit pas chaque classe. Pour obtenir des informations complètes sur toutes les interfaces, lire la documentation Javadoc.
La plupart des ressources contiennent un identificateur. Vous pouvez utiliser ce dernier pour les adresser ou les localiser. Cet identificateur est défini avec l'interface Identifiable qui vous permet d'extraire l'ID d'un élément. Un ID objet identifie un élément de manière unique dans une installation et au-delà (l'ID est également appelé GUID : identificateur unique universel). Un ID objet peut éventuellement posséder un nom unique (nom qui ne peut exister qu'une fois dans chaque installation) pour simplifier le traitement d'éléments spécifiques.
N'utilisez pas toString sur des ID objet. La représentation explicite renvoyée ne peut pas être analysée comme objet ObjectID. Pour une conversion entre un objet ObjectID et sa représentation sous forme de chaîne, utilisez l'interface Identification (voir le module com.ibm.portal.identification).
Une opération commune consiste à rechercher des ressources ayant un ID objet spécifique. Pour permettre l'exécution de cette opération, le concept de localisateur est introduit. Un localisateur est fourni par un modèle et permet de rechercher des éléments du modèle de manière spécifique. Pour obtenir cet objet localisateur, vous devez utiliser la méthode getLocator d'un objet qui implémente l'interface LocatorProvider.
Vous pouvez utiliser l'interface de localisateur générique pour localiser une ressource par son ID objet (findByObjectID) ou par son nom unique (findByUniqueName). Certains modèles fournissent des localisateurs spécialisés qui développent le localisateur générique pour proposer des fonctions de recherche supplémentaires, telles que la recherche par titre ou d'autres critères.
D'un point de vue générique, les modèles sont des listes ou des arborescences. Par conséquent, les interfaces TreeModel et ListModel sont fournies dans le module principal. Dans un modèle d'arborescence, vous pouvez exécuter les tâches suivantes :
- Obtenir le noeud racine d'un modèle d'arborescence (getRoot)
- Analyser les enfants d'un noeud du modèle (hasChildren)
- Obtenir les enfants d'un noeud du modèle (getChildren)
- Obtenir le parent d'un noeud du modèle (getParent)
Avec ces méthodes, vous pouvez explorer un modèle d'arborescence. Vous devez obtenir les arguments d'entrée qui représentent les noeuds du modèle à partir du modèle proprement dit.
Combiné au concept de localisateur abordé précédemment, un modèle d'arborescence devient un modèle explorable de l'arborescence : SearchableTreeModel est un modèle de l'arborescence également développé à partir de LocatorProvider.
Certains modèles prennent également la forme d'une liste, par exemple la liste des balisages ou la liste des langues prises en charge par HCL. La méthode générique pour accéder directement aux éléments de la liste consiste à utiliser l'itérateur fourni (méthode de l'itérateur). Lorsqu'une méthode renvoie un modèle de liste, elle utilise l'interface ListModel. Cependant, dans certains cas, elle peut également renvoyer un élément PagedListModel, qui est développé à partir de ListModel et fournit en plus un itérateur paginé. Ainsi, les éléments du modèle de liste peuvent être obtenus par blocs, ce qui peut améliorer les performances par rapport à l'obtention de chaque élément séparé.
Les modèles de liste deviennent explorables à l'instar des modèles d'arborescence : SearchableListModel est un modèle de liste qui peut également être développé à partir de LocatorProvider.
com.ibm.portal.model).