Bevor Sie anfangen, müssen Sie die Übung 1.1: Ressourcen importieren ausführen.
In dieser Übung lernen Sie die konzeptionellen Unterschiede zwischen den beiden Portlet-APIs kennen.
Die IBM Portlet-API wurde ursprünglich für WebSphere Portal Version 4 entwickelt. Unterstützung für die JSR 168-Portlet-API wurde mit WebSphere Portal Version 5.0.2 bereitgestellt.
Die JSR 168-Portlet-API ist eine standardisierte JavaTM-Portletspezifikation, die von einer Gruppe unter der gemeinsamen Führung von IBM und Sun sowie unter Einbeziehung der wichtigsten Hersteller von Portalservern entwickelt wurde. Sie soll Kompatibilitätsprobleme zwischen Portalservern verschiedener Hersteller ausräumen. Die erste Spezifikation wurde im Oktober 2003 freigegeben.
WebSphere Portal unterstützt beide APIs. Das Produkt stellt zwei Container bereit: den traditionellen Container für IBM Portlet-API-Portlets (im Folgenden als IBM Portlets bezeichnet) und den Standardcontainer für JSR 168-Portlet-API-Portlets (im Folgenden als JSR 168-Portlets bezeichnet). Portlets, die in verschiedenen Containern ausgeführt werden, können sich auf derselben Portalseite befinden.
Ein Portalcontainer stellt die Laufzeitumgebung für Portlets bereit. Er unterstützt den Lebenszyklus des Portlets, der aus folgenden drei Phasen besteht:
Die Phase der Anforderungsverarbeitung ist in zwei Teilphasen untergliedert:
Bevor Sie sich mit speziellen Codierungsunterschieden befassen, müssen Sie einige grundsätzliche Unterschiede zwischen den beiden Portlet-APIs verstehen.
Beachten Sie, dass Sie nicht direkt mit dem Quellcode für die Portletimplementierungsdeskriptoren zu arbeiten brauchen, wie unten erläutert. Der Editor für Portletimplementierungsdeskriptoren stellt eine grafische Benutzeroberfläche für portlet.xml bereit und aktualisiert den Quellcode für Sie.
Ein Portlet wird beim erstmaligen Laden mit Parametern vom Webimplementierungsdeskriptor (web.xml) initialisiert. Die Parameter werden im Element <init-param> des Elements <servlet> definiert. Diese Parameter können mit der Methode getInitParameter() des Objekts PortletConfig abgerufen werden. Das daraus resultierende Portlet ist ein abstraktes Portlet.
Vor der Verwendung eines Portlets werden die Parameter vom Portletimplementierungsdeskriptor (portlet.xml) in ein Objekt PortletApplicationSettings oder PortletSettings geladen. Diese Parameter werden im Element <context-param> des Elements <concrete-portlet-app> und im Element <config-param> des Elements <concrete-portlet> definiert.
Die Parameter im Element <concrete-portlet-app> gelten für alle Portlets in der Portletanwendung. Sie können mit der Methode PortletSettings.getApplicationSettings() abgerufen werden. Die Methode getApplicationSettings() gibt ein Objekt PortletApplicationSettings zurück, und mit Hilfe von PortletApplicationSettings.getAttribute() werden die einzelnen Parameter abgerufen. Die Parameter im Element <concrete-portlet> gelten für bestimmte Portlets. Sie können mit der Methode PortletSettings.getAttribute() abgerufen werden.
Die Kombination aus einem abstrakten Portlet und den Daten eines Objekts PortletSettings wird als konkretes Portlet bezeichnet.
Beim Platzieren eines Portlets auf einer Portalseite wird ein Objekt PortletData erstellt. Die Kombination aus einem konkreten Portlet und einem Objekt PortletData wird als konkretes Portletexemplar bezeichnet. Die PortletData-Objekte verwalten die persistenten Daten für die konkreten Portletexemplare. Die Werte werden mit den Methoden PortletRequest.getData() und PortletData.getAttribute() abgerufen und mit den Methoden PortletData.setAttribute() und PortletData.store() gespeichert. Die Daten werden auf einen Benutzer oder eine Gruppe zugeschnitten, je nach dem Umfang der Portalseite.
Die Kombination aus einem konkreten Portletexemplar und einem Objekt PortletSession wird als Benutzerportletexemplar bezeichnet.
Die folgende Abbildung zeigt die gerade besprochenen Objekte.
![]() |
Mit Hilfe der JSR 168-Portlet-API werden die Anfangsparameter in portlet.xml mit dem Element <portlet-preferences> definiert. Das Element <init-param> in web.xml bei der IBM Portlet-API entspricht dem Element <init-param> in portlet.xml bei der JSR 168-Portlet-API.
Diese Anfangsparameter können auf schreibgeschützt gesetzt werden, können jedoch während der Laufzeit im Konfigurationsmodus geändert werden. Schreibgeschützte Initialisierungsparameter können nur von einem Administrator geändert werden. Bei Änderungen während der Laufzeit kann eine Prüfprogrammklasse aufgerufen werden. Der Name der Prüfprogrammklasse wird ebenfalls im Element <portlet-preferences> definiert. Das Objekt PortletPreferences macht diese Parameter mit Hilfe der Methoden RenderRequest.getPreferences(), PortletPreferences.getValue() und PortletPreferences.getValues() für das Portlet verfügbar. Das Element <portlet-preferences> entspricht dem Element <config-param> in Verbindung mit einem Objekt PortletData bei der IBM Portlet-API.
Die Kombination aus einem Objekt PortletPreferences und einem Portlet wird als Portletentität bezeichnet. Ein Portletfenster ist definiert als die Kombination aus dem Portletmodus (Bearbeitungs- oder Anzeigemodus), dem Portletfensterstatus (normal, maximiert, minimiert) und den Wiedergabeparametern. Eine Portalseite kann mehrere Portletfenster für ein Portlet enthalten, von denen jedes einem bestimmten Modus, Status und bestimmten Wiedegabeparametern zugeordnet ist.
Die folgende Abbildung zeigt die gerade besprochenen Objekte.
![]() |
Beide Portlet-APIs verwenden einen Lebenszyklus, der eine Phase der Initialisierung, der Anforderungsverarbeitung und der Auflösung umfasst. Die Anforderungsverarbeitung ist in Teilphasen untergliedert: die Aktionsverarbeitung und die Inhaltswiedergabe. Genauere Informationen zur Phase der Anforderungsverarbeitung finden Sie im Abschnitt Anforderungsverarbeitung. Die in den einzelnen Phasen aufgerufenen Methoden sind unten aufgeführt.
Beide Portlet-APIs verwenden Anforderungsverarbeitung in zwei Phasen. Zuerst werden Aktionen (oder Ereignisse) verarbeitet, danach wird die Wiedergabephase aufgerufen. Bei der IBM Portlet-API wird die Aktionsphase mit der Methode actionPerformed() und die Wiedergabephase mit der Methode service() aufgerufen. Bei der JSR 168-Portlet-API werden die Phasen mit den Methoden processAction() und render() aufgerufen.
Ein großer Unterschied zwischen den beiden APIs besteht darin, dass die JSR-Portlet-API in der Aktions- und Wiedergabephase unterschiedliche Anforderungs- und Antwortobjekte verwendet, während die IBM Portlet-API in den beiden Phasen dieselben Objekte verwendet. Bei der IBM Portlet-API können Sie bei der Ereignisverarbeitung Attribute für die Anforderungs- und Antwortobjekte definieren und die Werte in der Wiedergabephase abrufen. Bei der JSR-Portlet-API können Attributwerte mit Sitzungsobjekten oder Wiedergabeparametern übergeben werden.
Ein weiterer Unterschied liegt darin, dass die Methode actionPerformed() der IBM Portlet-API mit Hilfe ihres Parameters ActionEvent Zugriff auf das Objekt PortletRequest erhält. Die Methode processAction() der JSR 168-Portlet-API besitzt die Parameter ActionRequest und ActionResponse, welche die Schnittstellen PortletRequest und PortletResponse implementieren.
Nun sind Sie bereit für die Übung 1.3: Unterschiede zwischen JavaTM-Klassen vergleichen.