Übung 1.2: Konzeptionelle Unterschiede zwischen den APIs

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.

Übersicht

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.

Klassenexemplare und -daten mit Verwendung der IBM Portlet-API

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.
Logische Darstellung der Portletklassen und -daten in der IBM Portlet-API

Klassenexemplare und -daten mit Verwendung der JSR 168-Portlet-API

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.
Logische Darstellung der Portletklassen und -daten in der JSR 168-API

Lebenszyklus von Portlets

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.

Lebenszyklusmethoden der IBM Portlet-API

init(PortletConfig)
Die Methode init() wird aufgerufen, wenn das Portlet in Betrieb genommen wird. Der Parameter PortletConfig stellt den Zugriff auf das Objekt PortletContext bereit.
initConcrete(PortletSettings)
Mit der Methode initConcrete() wird das konkrete Portlet mit dem Objekt PortletSettings initialisiert.
service(PortletRequest, PortletResponse)
Die Methode service() wird aufgerufen, wenn das Portlet seinen Inhalt wiedergeben muss. Die Methode service wird während des Lebenszyklus eines Portlets häufig aufgerufen. Mit service werden Methoden wie doView() und doEdit() aufgerufen, je nach dem Fensterstatus des Portlets. Die Methode service wird normalerweise in der implementierenden Portletklasse nicht überschrieben.
destroyConcrete(PortletSettings)
Die Methode destroyConcrete() wird aufgerufen, wenn das konkrete Portlet aus dem Betrieb genommen wird.
destroy(PortletConfig)
Die Methode destroy() wird aufgerufen, wenn das Portlet aus dem Betrieb genommen wird, was die Möglichkeit zum Bereinigen von Ressourcen bietet.

Lebenszyklusmethoden der JSR 168-Portlet-API

init(PortletConfig)
Die Methode init() wird aufgerufen, wenn das Portlet in Betrieb genommen wird. Der Parameter PortletConfig stellt den Zugriff auf das Objekt PortletContext bereit.
render(RenderRequest, RenderResponse)
Die Methode render() wird aufgerufen, wenn das Portlet seinen Inhalt wiedergeben muss. Mit render werden Methoden wie doEdit() und doView() aufgerufen, je nach dem Fensterstatus des Portlets. Die Methode render wird normalerweise in der implementierenden Portletklasse nicht überschrieben.
processAction(ActionRequest, ActionResponse)
Für die Methode processAction() sind die Objekte ActionRequest und ActionResponse als Parameter erforderlich.
destroy()
Die Methode destroy() wird aufgerufen, wenn das Portlet aus dem Betrieb genommen wird, was die Möglichkeit zum Bereinigen von Ressourcen bietet.

Anforderungsverarbeitung

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.

Nutzungsbedingungen | Feedback
(C) Copyright IBM Corporation 2000, 2005. Alle Rechte vorbehalten.