| Portlet | |
|---|---|
| Aktuelle Version: | JSR-362 (April 2017) |
Portlets sind beliebig kombinierbare Komponenten einer Benutzeroberfläche, die von einem Portalserver angezeigt und verwaltet werden. Sie erzeugen Fragmente von HTML-Code und fügen sich in einer Portalseite ein. Typischerweise besteht eine Portalseite aus vielen, nicht-überlappenden Portlet-Fenstern („Kacheln“), in denen jeweils ein Portlet ausgeführt wird. Beispiele für Portlets sind E-Mail, Wetterbericht, Diskussionsforen oder Nachrichten.
Ein Portlet ist dabei eine Erweiterung des Servlets, so wie der Portlet-Container (bspw. Pluto) eine Erweiterung des Servlet-Containers darstellt (bspw. Tomcat). Portlets bilden auf der Clientseite eine einfach zu benutzende Oberfläche innerhalb des Browsers (Fenster mit Schaltflächen zum Maximieren, Minimieren, Editieren, Hilfe). Intern, also auf Serverseite, kann nun eine beliebige Anwendung liegen, die ihre Darstellung auf das Portlet weiterleitet. Sie entsprechen somit einer Sicht ("View") im Rahmen des MVC-Konzeptes.
Portlets werden in der Regel für einen spezifischen Portalserver geschrieben und sind dann ohne Code-Änderung nur auf diesem lauffähig. Es gibt jedoch Bestrebungen, einen Standard zu schaffen; der wichtigste ist die Java Portlet Specification JSR-168. Portlets nach JSR-168[1] sind auf allen Portalservern ausführbar, die diesen Standard unterstützen.
Am 29. Januar 2002 wurde der JSR-168 eingereicht, der eine API für Portalanwendungen standardisieren soll. Der Prozess wurde von Alejandro Abdelnur (Sun) und Stefan Hepper (IBM) geführt. Die initiale Expert Group bestand aus der Apache Software Foundation, BEA, IBM und Sun Microsystems. Unterstützer des JSRs waren ursprünglich Accenture, die Apache Software Foundation, BEA, Boeing, Borland, Bowstreet, Capgemini, Citrix, DaimlerChrysler, Documentum, Enformia Ltd, Epicentric, Hewlett-Packard, Interwoven, Macromedia, McDonald Bradley, Oracle, Plumtree, SAP, Silverstream, Sybase, Tarantella, Inc. und Vignette.[2] Hewlett-Packard schied später aus, dafür kam Novell hinzu und Martin Scott Nicklous übernahm die Leitung der Wartung (Maintenance Lead).[3]
Der Community Review fand nach fast eineinhalb Jahren vom 16. April bis zum 23. Juni 2003 statt. Am 17. Juli 2003 begann der Public Review, der am 16. August beendet wurde und zur Veröffentlichung am 27. Oktober 2003 führte. Der JSR 168 stellt einen der wichtigsten Meilensteine in der Geschichte der Portale dar. Er ebnete den Weg für unabhängig vom verwendeten Portal entwickelte Portlets. Dies bietet den Kunden die Möglichkeit, Anwendungen zu schreiben, ohne sich an einen Anbieter binden zu müssen. Wenn auch dieser Gedanke nicht von allen Portalherstellern konsequent durchgesetzt wird, führte der JSR-168 dazu, dass es unterdessen viele Standardportlets gibt, die eine standardisierte Funktionalität unabhängig vom eingesetzten Portal anbieten und von vielen Drittanbietern auf den Markt kommen.
Die in der JSR-168 dokumentierte Portlet API 1.0 enthält 12 Klassen und 14 Interfaces. Von den 12 Klassen sind acht Exceptions. Die Spezifikation standardisiert das Zusammenspiel zwischen Portlet-Container und Portlets.
IBM hat mit dem Java Specification Request 162 den Grundstein für eine Standardisierung einer Portal-API gelegt. Der JSR 162 wurde am 8. Januar 2002 dem Java Community Process übergeben. In der Anfrageformulierung wurde ein Standard gefordert, der auf dem existierenden Java Servlet Standard aufsetzen sollte. Dieser sollte so erweitert werden, dass die Portlets nicht mehr wie Servlets als einzelne Seiten gesehen werden, sondern dass sich Seiten aus mehreren Portlets zusammensetzen, die ein einheitliches Erscheinungsbild teilen, und gewisse Grundfunktionalitäten gemeinsam haben.
Am 20. Januar 2002 wurde dieser JSR zurückgezogen.
Nur eine Woche nachdem IBM mit dem JSR-162 einen Vorschlag für eine Portlet API eingereicht hatte, zog Sun selbst nach, und brachte eine eigene Anfrage für eine Portletspezifikation in den Prozess ein. Diese wurde von den größten Konkurrenten IBMs unterstützt. Dazu gehörten unter anderem BEA, Plumtree, Vignette und Sybase. Interessanterweise wurden die Teile eines Portals auch hier als Portlets bezeichnet.
Auch diese Anfrage wurde am 20. Januar 2002 zurückgezogen.
Im Juli 2006 wurde das Early Draft 1 zur Portlet Specification 2.0 veröffentlicht, am 12. Juni 2008 dann die finale Version verabschiedet. Die Ergänzungen konzentrieren sich vor allem auf die Kommunikation zwischen Portlets, der sogenannten Inter-Portlet Kommunikation (IPC). Ein Portlet soll einen Event zu beliebigen Portlets der Portal-Seite schicken können. Die Verarbeitung von Events geschieht in einer zusätzlichen Phase des Portlet-Lebenszyklus: der processEvent-Phase. Sie erfolgt vor der render-Phase und nach der processAction-Phase. Ein Event kann über Aufruf der Methode setEvent des EventResponse Interface versendet werden. Sie kann aus den Methoden processAction und processEvent heraus aufgerufen werden. Events können im Deployment-Descriptor definiert sein und in der processAction-Methode des EventPortlet Interface verarbeitet werden. Alternativ kann die Implementierung des GenericPortlet dazu verwendet werden, Events zu verarbeiten. Dazu muss die Methode, die einen Event empfangen soll, mit einer speziellen Annotation gekennzeichnet sein.
Ein Beispiel zur Verarbeitung eines Events mittels einer mit Annotation gekennzeichneten Methode.
@ProcessEvent(Retention=RUNTIME, name="com.acme.foo")
public void processFoo(EventRequest request, EventResponse response) throws
PortletException, java.io.IOException {
//process event foo
}
Ein Beispiel zur Verarbeitung eines Events, der im Deployment-Descriptor definiert wurde.
<event-definition>
<name>com.acme.foo</name>
<java-type>java.lang.String</java-type>
</event-definition>
...
<portlet>
...
<supported-processing-event>
<name>com.acme.foo</name>
</supported-processing-event>
...
</portlet>
void processEvent(EventRequest req, EventResponse resp)
{
...
Event event = req.getEvent();
if ( "com.acme.foo".equals(event.getName() ) )
{
String payload = (String) event.getValue();
...
}
}
Im März 2013 wurde mit der Arbeit an der dritten Portlet-Spezifikation begonnen. Die Fertigstellung war für Ende 2014 geplant, tatsächlich wurde die Spezifikation April 2017 fertiggestellt.[4] Folgende Änderungen wurden umgesetzt:[5]