Avant de commencer, vous devez terminer l'Exercice 1.1 : Importation des ressources.
Dans cet exercice, vous allez connaître les différences conceptuelles entre les deux API de portlet.
l'API de portlet IBM a été initialement développée pour WebSphere Portal version 4. La prise en charge de l'API de portlet JSR 168 n'a été assurée qu'à partir de WebSphere Portal version 5.0.2.
L'API de portlet JSR 168 est une spécification de portlet Java normalisée, développée par un groupe géré conjointement par IBM et Sun, avec des contributions de la part des principaux fournisseurs de serveurs de portail. Elle a pour objectif de résoudre les problèmes de compatibilité de portlet entre les serveurs de portail des fournisseurs différents. La spécification initiale a été approuvée en octobre 2003.
WebSphere Portal prend en charge les deux API. Il fournit deux conteneurs de portail : le conteneur existant des portlets de l'API de portlet IBM (désignés par les portlets IBM) et le conteneur normalisé des portlets de l'API de portlet JSR 168 (désignés par les portlets JSR 168). Les portlets qui s'exécutent dans des conteneurs différents peuvent résider dans la même page de portail.
Un conteneur de portail fournit l'environnement d'exécution des portlets. Il prend en charge le cycle de vie du portlet, qui se compose de trois phases :
La phase de gestion des demandes comprend elle-même deux sous-phases :
Avant de connaître les différences de codage spécifiques, vous devez comprendre certaines différences de base entre les deux API de portlet.
Il n'est pas nécessaire d'utiliser directement le code source des descripteurs de déploiement de portlet, comme indiqué ci-après. L'éditeur de descripteur de déploiement de portlet fournit une interface graphique pour portlet.xml et met à jour le code source à votre place.
Lorsqu'un portlet est chargé pour la première fois, il est initialisé avec des paramètres issus du descripteur de déploiement Web (web.xml). Ces paramètres sont définis dans l'élément <init-param> de l'élément <servlet>. Il est possible de les extraire à l'aide de la méthode getInitParameter() de l'objet PortletConfig. Le portlet qui en résulte est un portlet abstrait.
Avant qu'un portlet puisse être utilisé, les paramètres du descripteur de déploiement de portlet (portlet.xml) sont chargés dans un objet PortletApplicationSettings ou PortletSettings. Ces paramètres sont définis dans l'élément <context-param> de l'élément <concrete-portlet-app> et dans l'élément <config-param> de l'élément <concrete-portlet>.
Les paramètres de l'élément <concrete-portlet-app> s'appliquent à tous les portlets de l'application de portlet ; ils peuvent être extraits via la méthode PortletSettings.getApplicationSettings(). La méthode getApplicationSettings() renvoie un objet PortletApplicationSettings et PortletApplicationSettings.getAttribute() permet d'extraire les paramètres individuels. Les paramètres de l'élément <concrete-portlet> s'appliquent à des portlets spécifiques ; ils peuvent être extraits via la méthode PortletSettings.getAttribute().
La combinaison d'un portlet abstrait et de données provenant d'un objet PortletSettings est appelée portlet concret.
Lorsqu'un portlet est placé sur une page de portail, un objet PortletData est créé. La combinaison d'un portlet concret et d'un objet PortletData est appelée instance de portlet concret. Les objets PortletData gèrent les données persistantes des instances de portlet concret. Les valeurs sont extraites via les méthodes PortletRequest.getData() et PortletData.getAttribute(), puis stockées à l'aide des méthodes PortletData.setAttribute() et PortletData.store(). Les données sont sectorisées à un utilisateur ou un groupe, en fonction de la portée de la page de portail.
La combinaison d'une instance de portlet concret et d'un objet PortletSession est appelée instance de portlet utilisateur.
L'illustration suivante représente les objets décrits.
![]() |
Dans le cas de l'API de portlet JSR 168, les paramètres initiaux sont définis dans portlet.xml dans l'élément <portlet-preferences>. L'élément <init-param> dans web.xml de l'API de portlet IBM est équivalent à l'élément <init-param> dans portlet.xml de l'API de portlet JSR 168.
Il est possible de définir ces paramètres initiaux en lecture seule et de les modifier lors de l'exécution en mode configuration. Seul un administrateur peut modifier les paramètres d'initialisation en lecture seule. Dans ce cas, une classe de valideur peut être appelée. Son nom est également définie dans l'élément <portlet-preferences>. L'objet PortletPreferences met ces paramètres à disposition du portlet via les méthodes RenderRequest.getPreferences(), PortletPreferences.getValue() et PortletPreferences.getValues(). L'élément <portlet-preferences> équivaut à l'élément <config-param> plus un objet PortletData dans l'API de portlet IBM.
La combinaison d'un objet PortletPreferences et d'un portlet est appelée entité de portlet. Une fenêtre de portlet est la combinaison du mode du portlet (édition, affichage) de l'état de la fenêtre de portlet (normale, agrandie, réduite) et des paramètres d'affichage. Une page de portail peut inclure plusieurs fenêtres de portlet pour un portlet donné, chacune étant associée à un mode, un état et un ensemble de paramètres d'affichage spécifiques.
L'illustration suivante représente les objets décrits.
![]() |
Les deux API de portlet ont un cycle de vie composé d'une phase d'initialisation, d'une phase de traitement des demandes et d'une phase de destruction. La phase de traitement des demandes est divisée en deux sous-phases : le traitement des actions et l'affichage du contenu. La phase de traitement des demandes est détaillée dans Traitement des demandes. Les méthodes spécifiques appelées dans chacune des phases sont répertoriées ci-après.
Les deux API de portlet utilisent un traitement des demandes en deux phases. Les actions (ou événements) sont d'abord traitées, puis la phase d'affichage est appelée. Dans le cas de l'API de portlet IBM, la phase relatives aux actions est appelée via la méthode actionPerformed() et la phase d'affichage via la méthode service(). Dans le cas de l'API de portlet JSR 168, les phases sont respectivement appelées via les méthodes processAction() et render().
L'API de portlet JSR 168 utilise différents objets de demande et de réponse dans les phases relatives aux actions et à l'affichage, à la différence de l'API de portlet IBM, qui fait appel aux même objets dans ces deux phases. Avec l'API de portlet IBM, vous pouvez définir des attributs sur les objets de demande et de réponse lors du traitement des événements et extraire les valeurs lors de la phase d'affichage. En revanche, l'API de portlet JSR 168 permet de transmettre les valeurs d'attribut via l'objet session ou grâce aux paramètres d'affichage.
La méthode actionPerformed() de l'API de portlet IBM utilise son paramètre ActionEvent pour avoir accès à l'objet PortletRequest, à la différence de la méthode processAction() de l'API de portlet JSR 168, qui est dotée des paramètres ActionRequest et ActionResponse implémentant les interfaces PortletRequest et PortletResponse.
A présent, vous êtes prêt à commencer l'Exercice 1.3 : Comparaison des classes Java.