Workshop: Eclipses Rich Client Platform als Basis für eigene Anwendungen

Die Idee, Anwendungen dynamisch mit Plugins zu erweitern, ist nicht neu. Die Eclipse-Architektur war jedoch von Anfang an darauf ausgelegt, siehe Kasten "Die Eclipse-Architektur". Nur war das Framework bisher so stark auf Programmieranwendungen ausgerichtet, dass es fast unmöglich war, damit etwas anderes als eine IDE zu entwickeln.

Rich Clients - Fat Clients

Mit Version 3 hat Eclipse seine Orientierung auf IDEs aufgegeben. Grundlegende Teile lagerten seine Entwickler in Plugins aus, was die Programmierung eigener Anwendungen vereinfacht. Trotz dieser Fortschritte ist es immer noch nicht trivial, Eclipse-basierte Rich Clients zu entwickeln. Diese und die nächsten Coffeeshop-Folgen demonstrieren die Vorgehensweise an einer Beispielanwendung: einem Programm zum Management von digitalen Bildern.

Bei komplexen Anwendungen verkürzen Frameworks die Entwicklungszeit, insbesondere durch ein passendes Architekturmodell und erneut verwendbare Komponenten. Das ist auch der Ansatz der Eclipse Rich Client Platform, im Folgenden RCP abgekürzt. Sie taugt als Entwicklungsplattform vor allem, wenn sich mit ihrer Architektur das Anwendungsfeld gut modellieren lässt.

Für das Fotomanagement gibt es zwar schon diverse Open-Source-Lösungen, aber aus Sicht des Autors vermischen diese oft die spezifische Managementaufgabe mit der Bildbearbeitung (das kann Gimp besser) und verlieren so die eigentliche Aufgabe aus den Augen.

Eclipse Photo Management, kurz EPM, soll unterschiedliche Aspekte des Bildmanagements mit Eclipse-Views abdecken. EPM ist aus Gründen der Einfachheit keine Datenbankanwendung, es arbeitet mit Verzeichnissen von Bildern. Dabei sind typische verzeichnisorientierte Views einsetzbar, die von Filemanagern bekannt sind, etwa Detail, Icons oder Thumbnail-Preview. Neben den verzeichnisorientierten Views sind bildorientierte Views nötig: skalierbare Vorschauen, Anzeige von Exif-Daten oder frei definierbaren Metadaten (etwa Titel und Beschreibung).

Die Anwendung beherrscht verschiedene, auf das Archiv bezogene Aktionen: Bilder ins Archiv aufnehmen, löschen, drehen, Metadaten erfassen, suchen und exportieren. Alle diese Funktionen werden in diesem Workshop nicht ganz fertig programmiert, sondern nur so weit, wie zur Demonstration erforderlich. Sie zeigen, warum sich das RCP für diese Anwendung so gut eignet: Jede Funktionalität lässt sich als Plugin realisieren, die Anwendung ist auch nachträglich einfach erweiterbar.

Aus Eclipse-Sicht sind nicht nur die einzelnen Funktionalitäten Plugins, sondern die gesamte RCP-Anwendung. Erforderlich sind dafür mindestens folgende Komponenten: ein Hauptprogramm, eine Perspektive und ein so genannter Workbench Advisor. Letzterer ist eine unsichtbare technische Komponente, die das Aussehen der Anwendung (Menüs, Toolbars, Perspektiven) steuert. Views sind technisch nicht notwendig für eine lauffähige RCP-Anwendung, da aber eine Anwendung ohne Views eher langweilig wäre, soll diese Komponente hier nicht fehlen.

Aufbau über Plugins

Plugins müssen ein so genanntes Manifest namens »plugin.xml» mitliefern. Ein »find« im Eclipse-Verzeichnisbaum der Version 3.0.2 fördert 76 solcher Dateien (und damit Plugins) zutage - ein Zeichen für die hochgradige Modularisierung. Jedes Plugin besitzt ein eigenes Verzeichnis.

Eine RCP-Anwendung erweitert die Klasse »org.eclipse.core.runtime.applications«, ihre Perspektive leitet sich von »org.eclipse.ui.perspectives« ab. Ansonsten sind nur die beiden zentralen Plugins »org.eclipse.core.runtime« und »org.eclipse.ui« notwendig.

Selbstverständlich hilft Eclipse bei der Entwicklung von Plugins. Hierfür ist das Plugin Development Environment (PDE) zuständig. Es ist zu empfehlen, den aktuellen Milestone-Build von Eclipse 3.1 zu nutzen, denn gerade in Richtung RCP hat sich einiges getan. Dem Artikel liegt Eclipse in der Version 3.1M7 zugrunde, die auf den Projektseiten bereitsteht [1]. Der Download umfasst 91 MByte, entpackt sind es 104 MByte.

Nach dem Starten der Eclipse-IDE ruft der Entwickler mit »New Project« den Wizard auf, wählt »Plug-in Development | Plug-in Project« und schließlich die RCP-Anwendung (Abbildung 1). Die Properties lassen sich später noch ändern. Aus den verfügbaren Templates (Abbildung 2) wählt man ein passendes aus - das wird in der Praxis meist das letzte sein, da dieses Template am meisten vorgefertigte Funktionalität enthält. Um nicht in der Funktionsfülle das Wesentliche zu übersehen, soll für das Beispiel die einfachste Option genügen.

Abbildung 1: Der Wizard für ein neues Plugin verlangt unter anderem die Eingabe der Plugin-ID, des Namens und anderer Metadaten. Im unteren Bereich erlaubt er es, die Rich-Client-Option auszuwählen.

Abbildung 2: Für Rich-Client-Plugins bringt Eclipse verschiedene vorgefertigte Templates mit, die unterschiedliche Komplexität besitzen, vom einfachen Hello World bis zur umfassenden Mail-Anwendung.

01: package de.bablokb.epm;
02:
03: import org.eclipse.ui.application.IWorkbenchWindowConfigurer;
04: import org.eclipse.ui.application.WorkbenchAdvisor;
05: import org.eclipse.ui.application.WorkbenchWindowAdvisor;
06:
07: public class ApplicationWorkbenchAdvisor extends WorkbenchAdvisor {
08:
09:    private static final String PERSPECTIVE_ID = "EPM.perspective";
10:
11:     public WorkbenchWindowAdvisor createWorkbenchWindowAdvisor(IWorkbenchWindowConfigurer configurer) {
12:        return new ApplicationWorkbenchWindow Advisor(configurer);
13:     }
14:
15:    public String getInitialWindowPerspective Id() {
16:       return PERSPECTIVE_ID;
17:    }
18: }

01: package de.bablokb.epm;
02:
03: import org.eclipse.swt.graphics.Point;
04: import org.eclipse.ui.application.ActionBarAdvisor;
05: import org.eclipse.ui.application.IActionBarConfigurer;
06: import org.eclipse.ui.application.IWorkbenchWindowConfigurer;
07: import org.eclipse.ui.application.WorkbenchWindowAdvisor;
08:
09: public class ApplicationWorkbenchWindowAdvisor extends WorkbenchWindowAdvisor {
10:
11:     public ApplicationWorkbenchWindowAdvisor(IWorkbenchWindowConfigurer configurer) {
12:         super(configurer);
13:     }
14:
15:    public ActionBarAdvisor createActionBarAdvisor(IActionBarConfigurer configurer) {
16:       return new ApplicationActionBarAdvisor(configurer);
17:     }
18:
19:     public void preWindowOpen() {
20:         IWorkbenchWindowConfigurer configurer = getWindowConfigurer();
21:         configurer.setInitialSize(new Point(400, 300));
22:         configurer.setShowCoolBar(false);
23:         configurer.setShowStatusLine(false);
24:         configurer.setTitle("Eclipse Photo Management");
25:     }
26: }

Abbildung 3: Das Beispielprogramm zum Fotomanagement während der Entwicklung: Noch beschränkt es sich auf eine leere Eclipse-Perspektive.

Das Manifest »plugin.xml« des Beispiels erstellt der Wizard automatisch. Ein Doppelklick im Package-Explorer öffnet den passenden Editor, der die Pflege des Manifests auch ohne Kenntnis der XML-Struktur erlaubt. Neben der Hauptklasse »Application.java«, der Life-Cycle-Klasse »EPMPlugin.java« und der Klasse »Perspective.java« zum Implementieren der Default-Perspektive hat der Wizard drei Advisor-Klassen erzeugt.

Die Klasse »ApplicationWorkbenchAdvisor.java« (Listing 1) erweitert »WorkbenchAdvisor«. Wichtigste Methode ist »getInitialWindowPerspectiveId()« (Zeile 15), um die anfängliche Perspektive festzulegen - im Beispiel die eigene EPM-Perspektive. Außerdem dient die Klasse als Factory für einen »WorkbenchWindowAdvisor« (Zeile 11). Auch dessen Code ist recht kurz, siehe Listing 2. Die Methode »preWindowOpen()« (Zeile 19) regelt den Lebenszyklus von Fenstern, im Beispiel setzt sie die Fenstergröße, den Titel und weitere Widgets.

Die generierte Anwendung lässt sich aus dem Plugin-Editor heraus starten (über »Overview«), allerdings ist bislang wenig zu sehen (Abbildung 3) - es gibt ja außer einer Perspektive noch keine visuellen Komponenten in Form von Views.