Übung 1.3: Unterschiede zwischen den Java-Klassen vergleichen

Bevor Sie anfangen, müssen Sie die Übung 1.2: Konzeptionelle Unterschiede zwischen den APIs ausführen.

In dieser Übung lernen Sie die Unterschiede bei der Codierung der Java-Klassen zwischen den beiden Portlet-APIs kennen. Untersuchen Sie die beiden Versionen der Java-Klasse BookmarkPortlet. Beachten Sie die Hauptunterschiede zwischen den beiden APIs:

Basisportletklassen importieren

Die beiden APIs importieren unterschiedliche Portletklassen.

IBM Portlet-API
import org.apache.jetspeed.portlet.*;
JSR 168-Portlet-API
import javax.portlet.*;

Java-Klassenvererbung

Die beiden APIs erben von unterschiedlichen Klassen. Die IBM Portlet-API erweitert org.apache.jetspeed.portlet.PortletAdapter, wodurch eine Standardimplementierung der Schnittstelle org.apache.jetspeed.portlet.Portlet bereitgestellt wird. Diese Portletklasse erweitert HttpServlet, so dass IBM Portlets eine Art Servlet darstellen. Die JSR 168-Portlet-API stellt eine Klasse javax.portlet.GenericPortlet bereit, die die Schnittstelle javax.portlet.Portlet implementiert.

IBM Portlet-API
public class BookmarkPortlet extends PortletAdapter implements ActionListener
JSR 168-Portlet-API
public class BookmarkPortlet extends GenericPortlet

Anforderungs- und Antwortobjekte

Die Namen der Anforderungs- und Antwortobjekte der Methoden render (JSR 168-API) bzw. service (IBM API), beispielsweise doView() und doEdit(), unterscheiden sich. Die IBM Portlet-API verwendet die Objekte PortletRequest und PortletResponse. Die JSR 168-API dagegen verwendet die Objekte RenderRequest und RenderResponse. RenderRequest und RenderResponse erweitern jeweils die Objekte PortletRequest und PortletResponse und stellen eine einheitliche Funktionalität bereit.

IBM Portlet-API
public void doEdit(PortletRequest request, PortletResponse response)
JSR 168-Portlet-API
public void doEdit(RenderRequest request, RenderResponse response)

JSP-Dateien einschließen

Die IBM Portlet-API schließt JSP-Dateien mit dem Objekt PortletContext ein. Die JSR 168-Portlet-API verwendet dazu das Objekt PortletRequestDispatcher. Bei der Einschließungsaktion wird die angegebene JSP-Datei aufgerufen.

IBM Portlet-API
getPortletConfig().getContext().include(EDIT_JSP, request, response);
JSR 168-Portlet-API
PortletRequestDispatcher rd = getPortletContext().getRequestDispatcher(jspName);
rd.include(request, response);

Portletdaten

Die IBM Portlet-API speichert Benutzerdaten in einem Objekt PortletData. Die JSR 168-Portlet-API speichert ähnliche Informationen in einem Objekt PortletPreferences.

IBM Portlet-API
PortletData prefs = portletRequest.getData()
JSR 168-Portlet-API
PortletPreferences prefs = renderRequest.getPreferences()

Aktionsverarbeitung

Bei der IBM Portlet-API muss die Java-Klasse die Schnittstelle ActionListener durch die Bereitstellung einer Methode actionPerformed() implementieren. Bei der JSR 168-Portlet-API muss die Java-Klasse eine Methode processAction() bereitstellen. Ein Listener ist nicht erforderlich.

IBM Portlet-API
public void actionPerformed(ActionEvent event) throws PortletException
JSR 168-Portlet-API
public void processAction(ActionRequest request, ActionResponse response)

Namensbereichscodierung

Mit Hilfe der Namensbereichscodierung wird sichergestellt, dass die in einem Portlet verwendeten Variablen innerhalb des Portalcontainers eindeutig sind. Die nachstehenden Auszüge zeigen auch Methoden zur Namensbereichscodierung zur Verwendung in einer JSP-Datei an.

IBM Portlet-API
in einer Java-Klasse: PortletResponse.encodeNamespace()
in einer JSP-Datei:   <portletAPI:encodeNamespace/>
JSR 168-Portlet-API
in einer Java-Klasse: RenderResponse.getNamespace()
in einer JSP-Datei:   <portlet:namespace/>

Nun sind Sie bereit für die Übung 1.4: Unterschiede zwischen den Implementierungsdeskriptoren vergleichen.

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