Java Reference
In-Depth Information
Die Nutzung eines Erweiterungspunkts wird durch das XML-Element <extension> ange-
zeigt:
<extension point="...">
...
</extension>
Bitte beachten Sie den wichtigen Unterschied, den der Bindestrich ausmacht! Im ersten Fall
geht es um das XML-Element <extension-point> (mit Bindestrich), im zweiten Fall um das
Element <extension> mit dem Attribut point (zwischen extension und point ist in diesem
Fall kein Bindestrich, sondern ein Leerzeichen). Die drei Punkte zwischen <extension> und
</extension> stehen stellvertretend für weitere Angaben, die abhängig vom genutzten
Erweiterungspunkt sind. Die Struktur dieser Angaben muss konform zu dem XML-Schema
sein, das bei der Defi nition des Erweiterungspunkts festgelegt wurde. Als Beispiele für sol-
che Angaben können Sie sich Beschri ungen für die Oberfl ächenelemente (z. B. Menüein-
träge oder Views) vorstellen. Sehr häufi g, aber nicht unbedingt bei allen Erweiterungspunk-
ten notwendig ist der vollständige Name einer Klasse, von der dann Objekte generiert
werden (Plugins ohne Programmcode sind zum Beispiel solche, die Hilfetexte bereitstellen).
Genauer betrachtet heißt das, dass das Plugin, das einen Erweiterungspunkt defi niert, die
K o n fi gurationsangaben aller Nutzungen dieses Erweiterungspunkts auslesen und, falls
eine Einstiegsklasse spezifi ziert ist, von dieser Klasse Objekte erzeugen kann. Daraus folgt,
dass die Frage „wer initialisiert und erzeugt welches Objekt?“ für das Beispiel aus Bild 10.3
beantwortet werden kann, indem man sich die Pfeile in umgekehrter Richtung vorstellt. Das
Plugin1 erzeugt also beispielsweise Objekte von Klassen aus den Plugins 2, 3 und 4.
Die Plugins von Eclipse nutzen in der Regel den Mechanismus der Erweiterungspunkte, um
Objekte einer Einstiegsklasse zu erzeugen, so dass in den OSGi-Manifest-Dateien im Nor-
malfall keine Bundle-Activator-Zeile zur Angabe einer Einstiegsklasse vorhanden ist. Dies
ist vergleichbar mit den Declarative Services von OSGi, wo auch kein Bundle-Activator defi -
niert werden muss und Objekte anhand der Angaben in den XML-Dateien generiert werden.
Der Programmcode von solchen Plugins, welche sich an die oben beispielha angegebenen
Erweiterungspunkte zum Hinzufügen von Menüs, Menüeinträgen, Views, Editoren usw.
andocken, basiert in der Regel immer auf SWT und JFace, also den Bibliotheken für die
Programmierung grafi scher Benutzeroberfl ächen (beim Hinzufügen eines Menüeintrags
gibt man den Programmcode an, der beim Auswählen des Eintrags ausgeführt wird; beim
Hinzufügen einer View gibt man den Programmcode an, der die View füllt usw.). Gute
Kenntnisse von SWT und JFace sind deshalb für Entwickler „ernstha er“ Eclipse-Plugins
unverzichtbar. In unserem Demonstrationsbeispiel dieses Kapitels werden wir die Nutzung
von SWT auf ein Minimum reduzieren, JFace wird sogar überhaupt nicht verwendet.
1 0 .2 Komponentenmodell von Eclipse
Aus den Erläuterungen des vorhergehenden Abschnitts ergibt sich das Komponentenmodell
von Eclipse, ohne dass dazu noch viel erklärt werden muss: Eine Eclipse-Komponente bzw.
ein Eclipse-Plugin ist eine OSGi-Komponente mit einer zusätzlichen Konfi gurationsdatei
 
Search WWH ::




Custom Search