Génération d'URL dans HCL Portal

Générer correctement des URL de portail est l'une des tâches les plus importantes lors de la programmation d'une application basée sur HCL Portal. Plusieurs outils et techniques de programmation permettent de générer des URL HCL Portal dans du code personnalisé. La section ci-après présente les outils de programmation disponibles et indique les recommandations d'utilisation pour chacun d'eux.

Types d'URL de portail

Il existe plusieurs types d'URL de portail selon la tâche que vous tentez d'exécuter.
URL de rendu
Ce type d'URL permet d'extraire une vue générale d'une page de portail. Il n'inclut pas d'action de portlet spécifique et n'entraîne pas de changement d'état côté serveur. Une URL de rendu correspond à une opération HTTP GET et est de type idempotent, ce qui signifie qu'elle peut être exécutée plus d'une fois sans cause de dommage. La navigation de page HCL Portal normale est constituée d'URL de rendu.
URL d'action
Les URL d'action sont utilisées pour les activités au sein des portlets. Ces URL correspondent à des demandes HTTP POST ou PUT et sont souvent de type non idempotent, ce qui signifie qu'elles ne doivent être exécutées qu'une seule fois. En général, une URL d'action cible un portlet spécifique et peut entraîner des changements d'état côté serveur. L'action de portlet et le portlet sur lequel l'action est ciblée sont transmis en tant que paramètres dans le document d'état de navigation.
URL conviviales
Les URL conviviale comportent des chaînes lisibles décrivant le chemin d'accès à une page de portail. Ces chaînes lisibles correspondent aux noms d'URL conviviale qui sont associés aux pages ou aux libellés. En outre, l'URL peut également comporter des jetons de chemin de contenu conviviaux. Ces derniers sont des chaînes lisibles qui décrivent le chemin de zone de site vers la bibliothèque de contenu Web associée à la page.
Remarque : Une URL conviviale peut également inclure un document d'état de navigation codé. Si ce n'est pas le cas, il s'agit d'une URL conviviale sans état. Il existe une API de programmation spécialement conçue pour fonctionner avec des URL conviviales.
URL de redirection
Les URL personnalisées sont similaires aux URL conviviales sans état ; elles sont lisibles et ne comportent pas de document d'état de navigation codé. Toutefois, les URL personnalisées ne sont pas liées aux noms d'URL conviviale associés aux pages de portail. Elles sont destinées à servir d'alias simples, faciles à mémoriser et faciles à saisir manuellement, le cas échéant. Les URL personnalisées sont similaires aux URL mappées qui ont été introduites dans les éditions précédentes d'HCL Portal. Elles sont uniquement destinées à servir de point d'entrée initial et ne sont pas permanentes dans la barre d'adresse du navigateur après le début de l'interaction avec le site de portail. Il existe une API de programmation spécialement conçue pour fonctionner avec des URL personnalisées.
URL de partie de contenu
Les URL de partie de contenu constituent un mécanisme de liaison tardive qui cible le contenu au lieu des artefacts de portail, tels que les pages. Ils utilisent un point d'entrée d'URL différent dans HCL Portal (en général, il s'agit de mypoc ou mycontenthandler au lieu de myportal). Il existe une API de programmation conçue pour fonctionner avec les URL de partie de contenu.

Méthodes de génération d'URL de portail

La complexité d'une URL HCL Portal rend son codage manuel difficile. Par conséquent, n'essayez pas de créer des URL de portail par concaténation de chaîne. L'intention liée à la conception est de faire en sorte que la plupart des URL de portail comportant des références circulaires soient générées dans le code lors de l'exécution, afin d'éviter l'apparition de liens rompus et la gestion manuelle de liens dans un site basé sur un portail.

HCL Portal met plusieurs options à la disposition d'un programmeur pour générer ces URL de portail complexes. Ces différentes options ont été conçues pour prendre en charge différents cas d'utilisation, du plus simple au plus complexe.
  • La méthode de balises JSP de portail est utilisée dans les fichiers JSP de thème et d'habillage.
  • L'API de portlet JSR 286 et les balises JSP correspondantes. Cette méthode de génération d'URL prend en charge la plupart des exigences de génération d'URL dans un portlet standard.
    • Ou bien, lorsque vous modifiez un portlet existant et qu'une mise à niveau est impossible, la précédente API de portlet JSR 168 est utilisée.
    • L'API de portlet HCL n'est plus prise en charge. Les portlets précédents qui sont écrits sur cette API doivent être migrés vers la norme en cours.
  • Paramètres de rendu public définis par HCL Portal. Cette méthode peut prendre en charge un grand nombre de cas d'utilisation qui nécessitaient l'API d'état de navigation.
  • La méthode d'API d'URL conviviale a été conçue spécialement pour les cas d'utilisation qui impliquent des URL conviviales, y compris les URL qui doivent être sans état (ne comportent pas de document d'état de navigation codé).
  • La méthode d'API d'URL PoC a été spécialement conçue pour créer des URL de contenu.
  • La méthode d'API d'URL personnalisée a été spécialement conçue pour fonctionner avec des URL personnalisées.
  • La méthode d'API d'état de navigation constitue l'outil de programmation général le plus complet pour la génération d'URL, mais elle est celle qui nécessite une connaissance approfondie et le plus de compétences en matière de programmation.

Lorsque vous créez des portlets coopératifs qui nécessitent des communications inter-portlet, la messagerie inter-portlet peut être transmise par le biais des URL qui sont générées. Les paramètres de rendu pris en charge par JSR 286 permettent d'implémenter cette technique, mais d'autres outils de programmation sont également fournis. Les techniques JSR 286 destinées aux portlets coopératifs et les autres outils de programmation sont décrits plus en détail dans la section Communication des portlets. Parmi ces autres outils de programmation, citons par exemple l'API de portlet coopératif pour l'interopérabilité entre les portlets JSR 286 et JSR 168 portlets.

Mappage de cas d'utilisation aux outils de programmation disponibles
Tableau 1. Méthodes de génération d'URL simples à complexes répertoriées pour différents cas d'utilisation
Tâche (de la plus simple à la plus complexe) Méthode de génération d'URL

Création de liens de navigation de pages entre les pages de portail au niveau du thème. Par exemple, la navigation de pages à onglets standard.

Ces URL sont généralement des URL de rendu simple. Dans les fichiers JSP, utilisez les balises JSP <portal-navigation/> . Pour plus d'informations sur la programmation d'un thème Portal, voir la section Développement de thèmes et d'habillages.

Un portlet JSR 286, autonome (aucune communication inter-portlet requise), qui génère des URL d'action vers lui-même et définit ses propres paramètres de rendu.
  • JSR 286 définit une bibliothèque de balises destinée à être utilisée dans des fichiers JSP. Cette bibliothèque de balises a été considérablement développée depuis la version V1.0/JSR168. Elle possède son propre espace de nom afin d'éviter tout conflit avec la bibliothèque V1.0.
    <%@ taglib uri="http://java.sun.com/portlet_2_0"
Prefix="portlet"%>
    Exemples :
    • Pour générer une URL de rendu normal avec un paramètre de rendu :
      <a href="<portlet:renderURL>
<portlet:param name="myRenderParameter"
value="someValue"/>
This is the text for the link</a>
    • Pour générer une URL d'action de portlet qui cible le portlet en cours sur la page en cours :
      form method="POST"
action="<portlet:actionURL/>">
      Remarque : Une URL d'action doit être codée avec le document d'état de navigation.
  • Pour obtenir un résultat équivalent en code Java, au lieu d'utiliser les balises JSP, utilisez l'API de portlet JSR 286 Portlet, qui se trouve dans le module javax.portlet. Pour plus d'informations, voir le lien connexe Module javax.portlet. Plus particulièrement, voir l'interface RenderResponse. Un élément RenderResponse est transmis à la méthode de rendu du portlet par le conteneur de portlet. Un élément RenderResponse implémente un élément MimeResponse, lequel fournit 3 méthodes permettant de créer des URL auto-référentielles.
    • createRenderURL()
    • createActionURL()
    • createResourceURL()

Portlet JSR 286, qui nécessite une communication interportlet avec un autre portlet JSR 286, mais aucune navigation de pages (la vue de portail reste sur la page en cours).

L'utilisation du support de paramètre de rendu JSR 286 peut suffire. Toutefois, il existe d'autres techniques. Pour plus d'informations, voir la section Communication de portlet.

Portlet JSR 286 qui doit interopérer avec un portlet JSR 168.

Un portlet JSR 168 qui fonctionnait avec d'autres portlets via une communication interportlet est écrite de manière à utiliser l'API de portlet coopératif, également appelée courtier de propriétés. Le courtier de propriétés a été une extension HCL vers la spécification JSR 168. JSR 286 a introduit le modèle d'événement de portlet, lequel a remplacé le courtier de propriétés. Les portlets JSR 286 et les portlets JSR 168 peuvent interopérer si certaines conditions sont remplies. Pour plus d'informations, voir la section Interopérabilité entre des événements de portlet JSR 286 et des portlets coopératifs JSR 168.
Portlet JSR 286 qui doit :
  • Générer un lien de rendu vers une autre page de portail (entraîne la navigation de pages)
  • Contrôler éventuellement le mode ou l'état de fenêtre du portlet ciblé
  • Contrôler éventuellement l'état du portail
  • Contrôler éventuellement les paramètres de rendu du portlet ciblé
  • Contrôler éventuellement l'environnement local de la demande générée
A compter de Portal 8.5 CF05, utilisez les paramètres de rendu public définis par HCL Portal pour tous ces cas d'utilisation, etc. Ces paramètres de rendu fournissent différents aspects du contexte de demande en cours sous forme de paramètres de rendu public normaux dans un espace de nom spécifié par HCL Portal.
Pour lire les valeurs d'état de navigation sous la forme de paramètres de rendu :
Ces paramètres de rendu public spéciaux sont accessibles via l'API JSR286 normale renderResponse.getParameter(<parameter qualified name>).

Où <parameter qualified name> est la concaténation de l'URI espace de nom (NAMESPACE_URI) et de l'un des noms de paramètre de rendu, comme défini dans la section ci-après. Par exemple, la sélection http://www.ibm.com/xmlns/prod/websphere/portal/publicparams.

Pour définir les valeurs d'état de navigation à l'aide de paramètres de rendu :
Ils peuvent être définis par l'API de portlet JSR286 normale baseURL.setParameter(<parameter qualified name>, <value>)

En définissant ces paramètres de rendu spécifiques à l'aide des API JSR286 normales, le système procède au codage des paramètres d'état de navigation appropriés dans le document d'état de navigation sur la nouvelle URL. Lorsque ce paramètre est utilisé, les nouvelles valeurs sont disponibles sur la demande suivante obtenue suite à l'affichage et à l'utilisation de cette nouvelle URL.

Notes :
  • Cette prise en charge requiert l'utilisation d'URL avec état car les paramètres de rendu sont inclus uniquement dans le document d'état de navigation codé.
  • Toutes ces valeurs sont disponibles en tant que constantes publiques dans la classe com.ibm.portal.PublicRenderParameters, API publique au sein du composant wp.model.api. Pour plus de détails, voir le Javadoc HCL Portal HCL Digital Experience Portal, Version 8.5.0.0 SPI Specification.
L'espace de nom du paramètre de rendu public spécifié par HCL portal est http://www.ibm.com/xmlns/prod/websphere/portal/publicparams (disponible sous la forme NAMESPACE_URI). Les éléments suivants sont les paramètres de rendu public spéciaux pris en charge par HCL Portal :
  • selection (NAME_SELECTION)
  • uri (NAME_URI)
  • parameters (NAME_PARAMETERS)
  • locale (NAME_LOCALE)
  • themeTemplate (NAME_THEME_TEMPLATE)
  • labelMappings (NAME_LABEL_MAPPINGS)
  • screenTemplate (NAME_SCREEN_TEMPLATE)
  • themePolicy (NAME_THEME_POLICY)
  • solo (NAME_SOLO)
  • showTools (NAME_SHOW_TOOLS)
  • hiddenContent (NAME_HIDDEN_CONTENT)
  • hiddenPages (NAME_HIDDEN_PAGES)
  • statePartition (NAME_STATE_PARTITION)
  • path-info (NAME_PATH_INFO)
  • focus (NAME_FOCUS)
  • deviceClass (NAME_DEVICE_CLASS)
  • digest (NAME_DIGEST)
  • pageMode (NAME_PAGE_MODE)
  • editMode (NAME_PAGE_EDIT_MODE)
  • infoMode (NAME_PAGE_INFO_MODE)
  • helpMode (NAME_PAGE_HELP_MODE)
Il existe également une API libre-service de génération d'URL Portal. Cette API libre-service ne prend en charge que les URL de rendu. Aucun changement d'état (URL d'action) ne peut être généré à l'aide de cette API. Les éléments suivants sont les classes de clés dans cette API :
  • com.ibm.portal.portlet.service.url.PortalURLGenerationService
  • com.ibm.portal.portlet.service.url.PortalURLWriter
Selon le Javadoc du module com.ibm.portal.portlet.service.url , un programmeur :
  1. Obtient une instance d'un élément PortletServiceHome via une recherche JNDI.
  2. Sur cette interface home, il appelle getPortletService(PortalURLGenerationService.class).
  3. Sur ce service, il appelle getPortalURLWriter(request, response).
  4. Utilise les méthodes sur l'objet PortalURLWriter afin de créer et manipuler l'URL de rendu.
Il existe un ensemble équivalent de balises JSP pour l'API pratique de génération d'URL. 
<%@ taglib uri="http://www.ibm.com/xmlns/prod/websphere/portal/v8/portlet/ibm-portlet-ext" prefix="portlet-ext" %>
Pour plus d'informations, voir Balises JSP pour les portlets standard. Exemple de création d'une URL de rendu à l'aide de la balise Convenience API : <portlet-ext:portalRenderURL>.

URL conviviale
Une URL conviviale également appelée nom d'URL conviviale est le nom lisible d'une page de portail. Elle est définie en tant qu'attribut de la page, et chaque page peut avoir une URL conviviale au maximum.
Notes :
  • Si une page comporte une URL conviviale correctement configurée, HCL Portal garantit que toute demande qui affiche cette page comporte cette URL conviviale. La demande ne contient pas l'URL conviviale uniquement si l'application de l'URL conviviale est explicitement désactivée à l'aide du paramètre de configuration friendly.redirect.enabled.
  • Il peut arriver que les URL conviviales comportent pas des informations d'état de navigation. Si des informations d'état de navigation doivent être retirées, d'autres techniques sont disponibles. Pour plus d'informations, lisez Définition d'URL conviviales sans informations d'état pour les pages de votre site et les balises <portal-navigation/>.
Pour utiliser l'API d'URL conviviale, vous devez obtenir une instance FriendlyURLFactory. Selon le type de code que vous écrivez, vous pouvez obtenir une instance FriendlyURLFactory de deux manières différentes :
Si vous écrivez un portlet :
  • Commencez par la classe com.ibm.portal.resolver.friendly.service.PortletFriendlySelectionServiceHome. Vous devez obtenir une instance de cette classe en exécutant 2 étapes :
    1. Effectuez une recherche JNDI à l'aide de la valeur PortletFriendlySelectionServiceHome.JNDI_NAME constante. Cette recherche JNDI renvoie une instance PortletServiceHome.
    2. Sur l'objet PortletServiceHome, appelez getPortletService(PortletFriendlySelectionServiceHome.class). L'appel renvoie une instance PortletFriendlySelectionServiceHome.
  • Pour plus d'efficacité, effectuez une recherche JNDI et un appel getPortletService dans la méthode init(PortletConfig) de votre portlet, puis enregistrez l'instance PortletFriendlySelectionsServiceHome à réutiliser. Il n'est pas nécessaire d'effectuer ces appels pour chaque demande.
  • Lors d'un appel par demande, tel que la méthode doView(RenderRequest,RenderResponse) du portlet, utilisez l'instance PortletFriendlySelectionServiceHome enregistrée pour appeler getPortletFriendlySelectionService(request,response). L'appel renvoie une instance PortletFriendlySelectionService.
    Remarque : Cette instance doit être supprimée en appelant dispose() avant d'être mise hors de portée.
  • Sur l'instance PortletFriendlySelectionService renvoyée, appelez getURLFactory().
Si vous écrivez un code à thème :
  • Commencez par la classe com.ibm.portal.resolver.friendly.service.PortalFriendlySelectionServiceHome. Effectuez une recherche JNDI à l'aide de la valeur PortalFriendlySelectionServiceHome.JNDI_NAME constante. Cette recherche renvoie une instance PortalFriendlySelectionServiceHome.
  • Pour plus d'efficacité, effectuez la recherche JNDI dans le constructeur ou une autre méthode d'initialisation de votre classe, puis enregistrez l'instance PortalFriendlySelectionServiceHome à réutiliser. Il n'est pas nécessaire d'effectuer cet appel pour chaque demande.
  • Lors d'un appel par demande, utilisez l'instance PortalFriendlySelectionServiceHome enregistrée pour appeler getPortalFriendlySelectionsService(HttpServletRequest,HttpServletResponse). L'appel renvoie une instance PortalFriendlySelectionService.
    Remarque : Cette instance doit être supprimée en appelant dispose() avant d'être mise hors de portée.
  • Sur l'instance PortalFriendlySelectionService renvoyée, appelez getURLFactory().

Une fois que vous disposez d'une instance FriendlyURLFactory, vous pouvez appeler l'une des méthodes newURL() pour obtenir une instance FriendlyURL. Une instance FriendlyURL peut être configurée à l'aide des méthodes set* qui sont écrites dans la réponse à l'aide de la méthode writer(Writer). La méthode Writer provient de la réponse ; elle est ensuite supprimée en appelant dispose().

URL personnalisée

Une URL personnalisée est une URL simple et facile à mémoriser qu'un utilisateur peut saisir manuellement. Les URL personnalisées sont gérées par le Webmaster à l'aide des outils d'administration d'HCL Portal, tels que la barre d'outils, les portlets administratifs ou le scriptage XMLAccess. Cependant, lorsque vous affichez une réponse, il peut s'avérer nécessaire de générer un lien d'URL personnalisée.

La section ci-après explique comment utiliser l'API d'URL personnalisée pour obtenir une instance VanityURLNode qui peut être utilisée afin d'afficher un lien URL personnalisée. Selon le type de module de code que vous développez, utilisez l'une des 3 méthodes pour accéder et utiliser l'API d'URL personnalisée.
Remarque : Prenez soin de sélectionner le module d'interface SPI approprié pour le code en cours de développement.
La documentation d'interface nécessaire figure dans le Javadoc sur l'interface SPI HCL Portal.
Si vous écrivez un portlet :
  • Localisez le module com.ibm.portal.portlet.service.model.
  • Commencez par l'interface VanityURLModelProvider. Vous devez obtenir une instance d'une classe qui implémente cette classe en exécutant 2 étapes :
    1. Obtenez une instance PortletServiceHome au moyen d'une recherche JNDI en utilisant la constante de nom VanityURLModelProvider.JNDI_NAME.
    2. Sur cet objet PortletServiceHome, appelez getPortletService(VanityURLModelProvider.class).
  • Effectuez la recherche JNDI et appelez getPortletService dans la méthode init() du portlet. Enregistrez l'instance VanityURLModelProvider renvoyée dans une zone statique de votre classe de portlet. Cette instance de fournisseur peut être réutilisée dans des demandes.
  • Pour chaque demande, par exemple dans l'appel à la méthode doView() du portlet, appelez getVanityURLModel sur l'instance VanityURLModelProvider enregistrée en transmettant la demande et la réponse de portlet en cours. Les modèles ne doivent pas être réutilisés dans les demandes.
  • Sur l'objet VanityURLModel, appelez getLocator().
  • Sur VanityURLModelLocator, vous pouvez appeler des méthodes findBy qui renvoient un élément VanityURLNode unique ou une liste IterableListModel<VanityURLNode>.
Si vous écrivez un code à thème :
  • Localisez le module com.ibm.portal.model.
    Remarque : De nombreux noms de classe de cet ensemble d'instructions sont identiques aux noms de classe utilisés pour la source de données de l'API d'URL personnalisée, mais le nom de module est différent.
  • Obtenez une instance d'une classe qui implémente VanityURLModelProvider en exécutant 2 étapes :
    1. Obtenez une instance VanityURLModelHome au moyen d'une recherche JNDI en utilisant la constante de nom VanityURLModelHome.JNDI_NAME. Pour obtenir un exemple de code, voir la documentation Javadoc com.ibm.portal.model.VanityURLModelHome.
    2. Sur cet objet VanityURLModelHome, appelez getVanityURLModelProvider().
  • Effectuez la recherche JNDI et appelez getVanityURLModelProvider() dans le constructeur ou une méthode init() de votre classe. Enregistrez l'instance VanityURLModelProvider renvoyée dans une zone statique de votre classe. Cette instance de fournisseur peut être réutilisée dans des demandes.
  • Pour chaque demande, appelez getVanityURLModel sur l'instance VanityURLModelProvider enregistrée en transmettant la demande et la réponse de servlet en cours. Les modèles ne doivent pas être réutilisés dans les demandes.
  • Sur l'objet VanityURLModel, appelez getLocator().
  • Sur VanityURLModelLocator, vous pouvez appeler des méthodes findBy qui renvoient un élément VanityURLNode unique ou une liste IterableListModel<VanityURLNode>.
Si vous écrivez une source de données :
  • Localisez le module com.ibm.portal.cor.service.
    Remarque : De nombreux noms de classe de cet ensemble d'instructions sont identiques aux noms de classe utilisés pour le code à thème de l'API d'URL personnalisée, mais le nom de module est différent.
  • Obtenez une instance d'une classe qui implémente VanityURLModelProvider en exécutant 2 étapes :
    1. Obtenez une instance VanityURLModelHome au moyen d'une recherche JNDI en utilisant la constante de nom VanityURLModelHome.JNDI_NAME. Pour obtenir un exemple de code, voir la documentation Javadoc com.ibm.portal.cor.service.VanityURLModelHome.
    2. Sur cet objet VanityURLModelHome, appelez getVanityURLModelProvider().
  • Effectuez la recherche JNDI et appelez getVanityURLModelProvider() dans le constructeur ou une méthode init de votre classe et enregistrez l'instance VanityURLModelProvider renvoyée dans une zone statique de votre classe. Cette instance de fournisseur peut être réutilisée dans des demandes.
  • Dans une méthode par demande de l'objet DataSource, appelez modelProvider.getVanityURLModel(com.ibm.content.operations.registry.api.Context).

    Détails de programmation pour un objet DataSource : dans la plupart des cas, un objet DataSource est alloué par une fabrique dédiée. La fabrique est enregistrée avec le canevas de programme de résolution pour traiter les demandes d'un URI donné. Lorsqu'une demande pour cet URI est reçue, la fabrique est démarrée par l'infrastructure du programme de résolution et reçoit un objet com.ibm.content.operations.registry.api.Context. Il est essentiel de bien comprendre la différence entre cet objet COR Context et la classe javax.naming.Context qui est utilisée par la recherche JNDI. La fabrique alloue une nouvelle instance DataSource (ou peut extraire une instance d'un pool) et appelle reset() sur l'instance DataSource en transmettant l'objet COR Context. Cet objet et les autres paramètres pour reset() doivent être enregistrés dans des zones d'instance au sein de DataSource. Ils peuvent être utilisés dans des appels de méthode suivants jusqu'à ce que dispose() soit appelé ou que reset() soit de nouveau appelé. Utilisez l'objet COR Context sur l'appel vers getVanityURLModel(com.ibm.content.operations.registry.api.Context).

  • Sur l'objet VanityURLModel, appelez getLocator().
  • Sur VanityURLModelLocator, vous pouvez appeler des méthodes findBy qui renvoient un élément VanityURLNode unique ou une liste IterableListModel<VanityURLNode>.
Une fois que vous avez obtenu une instance VanityURLNode au moyen de l'une des procédures appropriées, vous pouvez appeler les différentes méthodes de cette interface pour générer une représentation rendue de l'URL personnalisée :
  • VanityURLnode.isSecure() indique si le protocole cible est HTTP ou HTTPS.
  • VanityURLnode.isProtected() indique si l'URL cible est mappée à /portal ou /myportal.
  • VanityURLnode.getHost() renvoie le nom d'hôte associé à cette URL personnalisée.
  • VanityURLnode.getPort() renvoie le numéro de port associé à cette URL personnalisée.
  • VanityURLnode.getVpld() renvoie l'ID objet de portail virtuel pour cette URL personnalisée.
  • VanityURLnode.getPath() renvoie la chaîne de chemin pour cette URL personnalisée. Cette chaîne de chemin est considérée comme la chaîne d'URL personnalisée.

Créez, mettez à jour ou supprimez des URL personnalisées.

Si vous écrivez du code pour créer, mettre à jour ou supprimer des URL personnalisées au lieu de les lire et de les afficher, utilisez les API suivantes :
  • Localisez le module com.ibm.portal.model.controller.
  • Vous devez obtenir une instance d'une classe qui implémente VanityURLModelControllerHome au moyen d'une recherche JNDI en utilisant la constante de nom VanityURLModelControllerHome.JNDI_Name. Pour obtenir un exemple de code, voir la documentation Javadoc com.ibm.portal.model.controller.VanityURLModelControllerHome.
  • Sur cet objet VanityURLModelControllerHome, appelez getVanityURLModelControllerProvider().
  • Effectuez la recherche JNDI et appelez getVanityURLModelControllerProvider() dans le constructeur ou une méthode init de votre classe et enregistrez l'instance VanityURLModelControllerProvider renvoyée dans une zone statique de votre classe. Cette instance de fournisseur peut être réutilisée dans des demandes.
  • Vous devrez peut-être également obtenir un VanityURLModelProvider en utilisant le même code que celui décrit dans la rubrique consacrée à l'écriture de code à thème.
  • Dans une méthode par demande :
    • Sur VanityURLModelProvider, appelez getVanityURLModel(request,response).
    • Sur l'objet VanityURLModelControllerProvider, appelez createVanityURLModelController(model) en transmettant le modèle qui est renvoyé par l'appel émis versgetVanityURLModel.
  • Les appels suivants permettant d'écrire la nouvelle URL personnalisée et de définir ses attributs sont documentés dans la documentation Javadoc pour VanityURLModelController et ModifiableVanityURLNode.

Un portlet JSR 286 qui doit générer une URL d'action pour un second portlet spécifique ou dans n'importe quel autre cas d'utilisation non mentionné ici.

API d'état de navigation

URL de contenu

Une URL d'élément de contenu est une URL qui cible un objet DataSource ou ResolutionService dans l'infrastructure du programme de résolution. Avec ces éléments DataSource ou ResolutionService, l'API d'URL d'élément de contenu aide le programmateur à créer une URL qui conduit l'infrastructure du programme de résolution à démarrer l'élément DataSource ou ResolutionService approprié.

Pour gérer des URL d'élément de contenu, procurez-vous une instance com.ibm.portal.resolver.acessors.url.PocURLFactory. Tout comme pour d'autres API d'URL, le code permettant d'obtenir une instance URLFactory varie selon que vous écrivez un portlet, un code à thème ou que vous exécutez déjà un code dans l'infrastructure du programme de résolution.
Si vous écrivez un portlet :
  • Dans la documentation Javadoc sur le portail, localisez le module com.ibm.portal.resolver.servicer.service.
  • Obtenez une instance PortletPocServiceHome en exécutant 2 étapes :
    1. Effectuez une recherche JNDI pour l'instance PorletServiceHome en utilisant la constante de nom PortletPocServiceHome.JNDI_NAME. Pour obtenir un exemple de code, voir la documentation Javadoc pour PortletPocServiceHome.
    2. Sur l'objet PortletServiceHome renvoyé, appelez getPortletService(PortletPocServiceHome.class).
  • Effectuez la recherche JNDI et appelez getPortletService dans la méthode init(PortletContig) de votre portlet, puis enregistrez l'instance PortletPocServiceHome obtenue dans une variable d'instance de classe. Il n'est pas nécessaire de réexécuter ces appels sur chaque demande traitée par le portlet.
  • Dans une méthode par demande, comme render(RenderRequest,RenderResponse), appelez la méthode PortletPocServiceHome.getPortletPocService() appropriée en fonction de la méthode spécifique qui est implémentée et du type de la demande et de la réponse qui sont transmises. Il existe différentes versions de cette méthode pour une action, un événement, un rendu, une ressource et une demande et une réponse de portlet.
    Remarque : Il est nécessaire d'appeler dispose() sur l'instance de service renvoyée avant que celle-ci soit mise hors de portée.
  • Sur PortletPocService ou la sous-classe appropriée, appelez getURLFactory().
Si vous écrivez un code à thème :
  • Dans la documentation Javadoc sur le portail, localisez le module com.ibm.portal.resolver.service.
  • Effectuez une recherche JNDI pour l'instance PortalPocServiceHome en utilisant la constante de nom PortalPocServiceHome.JNDI_NAME.
  • Enregistrez l'instance PortalPocServiceHome obtenue dans une zone d'instance de classe. Il n'est pas nécessaire d'effectuer la recherche JNDI pour chaque demande.
  • Dans une méthode par demande de votre classe, sur l'instance PortalPocServiceHome enregistrée, appelez getPortalPocService en transmettant HttpServletRequest et HttpServletResponse.
    Remarque : Il est nécessaire d'appeler dispose() sur l'instance de service renvoyée avant que celle-ci soit mise hors de portée.
  • Sur l'instance PortalPocService obtenue, appelez getURLFactory().
Si vous écrivez du code qui s'exécute en tant que DataSource ou ResolutionService :
  • Dans la documentation Javadoc sur le portail, localisez le module com.ibm.portal.resolver.service.
  • Effectuez une recherche JNDI pour l'instance CorPocServiceHome en utilisant la constante de nom CorPocServiceHome.JNDI_NAME.
  • Enregistrez l'instance CorPocServiceHome obtenue dans une zone d'instance de classe. Il n'est pas nécessaire d'effectuer la recherche JNDI pour chaque demande.
  • Dans une méthode par demande de votre classe, sur l'instance CorPocServiceHome enregistrée, appelez getCorPocService(com.ibm.content.operations. registry.api.Context).
    Remarque : Il est nécessaire d'appeler dispose() sur l'instance de service renvoyée avant que celle-ci soit mise hors de portée.

    Détails de programmation pour un objet DataSource : dans la plupart des cas, un objet DataSource est alloué par une fabrique dédiée. La fabrique est enregistrée avec le canevas de programme de résolution pour traiter les demandes d'un URI donné. Lorsqu'une demande pour cet URI est reçue, la fabrique est démarrée par l'infrastructure du programme de résolution et reçoit un objet com.ibm.content.operations.registry.api.Context. Il est essentiel de bien comprendre la différence entre cet objet COR Context et la classe javax.naming.Context qui est utilisée par la recherche JNDI. La fabrique alloue une nouvelle instance DataSource (ou peut extraire une instance d'un pool) et appelle reset() sur l'instance DataSource en transmettant l'objet COR Context. Cet objet et les autres paramètres pour reset() doivent être enregistrés dans des zones d'instance au sein de DataSource. Ils peuvent être utilisés dans des appels de méthode suivants jusqu'à ce que dispose() soit appelé ou que reset() soit de nouveau appelé. Utilisez l'objet COR Context sur l'appel vers getCorPocService (com.ibm.content.operations.registry.api.Context).

  • Sur l'instance CorPocService obtenue, appelez getURLFactory().
Une fois que vous avez obtenu une instance PocURLFactory :
  • Appelez l'une des méthodes newURL pour instancier le type souhaité de PocURL.
  • Sur l'instance PocURL obtenue, appelez les méthodes setXXX pour définir vos attributs d'URL.
  • Diffusez l'URL vers la réponse et supprimez l'instance PocURL en appelant writeDispose(). L'instance Writer qui doit être utilisée par writeDispose doit provenir de l'argument de réponse envoyé à la méthode.