Basisstruktur der Workbench

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.

Workbench

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.

Workbench mit drei Sichten und einem Editor auf einer Seite

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. 

Seite

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

Perspektiven bieten eine zusätzliche Verwaltungsebene innerhalb der Workbench-Seite. Eine Perspektive definiert für eine bestimmte Benutzertask eine geeignete Zusammenstellung von Sichten, ihren jeweiligen Layouts und gültigen Aktionen. Benutzer können bei der Durcharbeitung von Tasks zwischen unterschiedlichen Perspektive umschalten.  Aus der Sicht der Implementierung steuert die aktive Perspektive des Benutzers, welche Sichten in der Workbench-Seite angezeigt werden, sowie deren Positionen und Größen. Editoren werden von einem Perspektivenwechsel nicht beeinflusst.

Sichten und Editoren

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 Fensterobjekte, 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() {
         // set focus to my widget.  For a label, this doesn't
         // make much sense, but for more complex sets of widgets
         // you would decide which one gets the focus.
      }
   }

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.