Für die Erstellung von komplexen Benutzerschnittstellen steht in der Workbench eine äußerst umfangreiche Gruppe von Klassen und Schnittstellen zur Verfügung. Glücklicherweise müssen Sie über keine detaillierten Kenntnisse zu allen diesen Komponenten verfügen, um einfache Operationen auszuführen. Zunächst werden einige Konzepte vorgestellt, die in der Workbench-Benutzerschnittstelle umgesetzt werden, sowie die entsprechende Struktur, die diesen Konzepten zu Grunde liegt.
Der Begriff Workbench wurde bislang als allgemeine Bezeichnung für "das Fenster, das beim Starten der Plattform geöffnet wird" verwendet. Als Einstieg in dieses Thema werden im Folgenden einige der optischen Komponenten genauer beschrieben, aus denen die Workbench besteht.
Wenn der Begriff "Workbench" im weiteren Verlauf dieser Erläuterungen verwendet wird, bezeichnet er das Workbench-Fenster (IWorkbenchWindow). Das Workbench-Fenster ist das Fenster der höchsten Ebene in einer Workbench. Es ist der Frame, der die Menüleiste, die Symbolleiste, die Statuszeile, die Direktaufrufleiste und die Seiten enthält. Im Allgemeinen müssen Sie das Workbench-Fenster nicht programmieren. Sie müssen lediglich wissen, dass es vorhanden ist.
Hinweis: Sie können mehrere Workbench-Fenster öffnen. Allerdings bildet jedes dieser Fenster in Bezug auf seine Editoren und Sichten eine abgeschlossene Einheit. Daher wird die folgende Erläuterung anhand eines einzelnen Workbench-Fensters verdeutlicht.
Aus Sicht des Benutzers enthält eine Workbench Sichten und Editoren. Es gibt wenige weitere Klassen, mit denen das Workbench-Fenster implementiert wird.
Innerhalb des Workbench-Fensters sehen Sie eine Seite (IWorkbenchPage), die ihrerseits wieder verschiedene Komponenten enthält. Seiten sind ein Implementierungsmechanismus, mit dem Komponenten gruppiert werden können. Normalerweise müssen Sie keine Programmierung für die Seite vornehmen. Im Kontext von Programmierung und Debug müssen Sie jedoch mit Seiten arbeiten.
Perspektiven bieten eine zusätzliche Verwaltungsebene innerhalb der Workbenchseite. Eine Perspektive definiert eine passende Sammlung von Sichten, ihr Layout sowie die Aktionen, die für eine bestimmte Benutzertask gültig sind. Benutzer können zwischen Perspektiven wechseln, wenn sie unterschiedliche Tasks ausführen. Aus Sicht der Implementierung steuert die aktive Perspektive des Benutzers, welche Sichten auf der Workbenchseite angezeigt werden und welche Positionen bzw. Größen verwendet werden. Editoren werden von Änderungen in einer Perspektive nicht beeinflusst.
Mit Sichten und Editoren beginnt der Übergang von Implementierungsdetails zu einigen allgemeinen Aspekten der Plug-in-Programmierung. Wenn Sie eine optische Komponente zur Workbench hinzufügen, müssen Sie festlegen, ob Sie diese in einer Sicht oder in einem Editor implementieren wollen. Diese Entscheidung basiert auf den folgenden Punkten:
Eine Sicht oder ein Editor wird jedoch immer gemäß einem allgemeinen Lebenszyklus erstellt.
Während dieses Lebenszyklus werden auf der enthaltenden Workbench-Seite Ereignisse ausgelöst, um die betreffenden Komponenten vom Öffnen, Aktivieren, Inaktivieren und Schließen der Sichten und Editoren zu unterrichten.
Dies kann so einfach sein, wie es sich anhört, und ist auch der Grund für die hervorragenden Einsatzmöglichkeiten von Sichten und Editoren. Eigentlich sind sie nur "Behälter" für Widgets, die so einfach oder komplex sein können, wie es Ihren Anforderungen entspricht. Die denkbar einfachste Sicht haben Sie bereits bei der Erstellung der Sicht "Hello World" kennen gelernt. Da Sie jetzt über umfangreichere Kenntnisse verfügen, wird das Beispiel noch einmal wiederholt:
package org.eclipse.examples.helloworld; import org.eclipse.swt.widgets.Composite; import org.eclipse.swt.widgets.Label; import org.eclipse.swt.SWT; import org.eclipse.ui.part.ViewPart; public class HelloWorldView extends ViewPart { Label label; public HelloWorldView() { } public void createPartControl(Composite parent) { label = new Label(parent, SWT.WRAP); label.setText("Hello World"); } public void setFocus() { // Mein Widget fokussieren. Bei einem Label ist dies nicht sehr // sinnvoll, bei einer komplexeren Gruppe von Widgets // sollten Sie jedoch festlegen, welches Objekt fokussiert werden soll. } }
Sie können feststellen, dass eine Methode dispose() nicht implementiert werden musste, weil lediglich in der Methode createPartControl(parent) eine Bezeichnung erstellt wurde. Wären etwa Benutzerschnittstellenressourcen wie Images oder Schriftarten zugeordnet worden, hätten diese entfernt werden müssen. Da die Klasse ViewPart erweitert wurde, wird die Implementierung von "do nothing" aus dispose() übernommen.