Eclipse Workbench, Views und Perspektiven
Aufbau der Eclipse-Workbench
Die Eclipse Workbench ist für die grafische Benutzeroberfläche einer RCP-Anwendung zuständig. Es handelt sich dabei um einen leeren Applikationsrahmen, der von den Plug-ins der jeweiligen Anwendung über Extensions befüllt wird. Die Workbench wird von dem Plug-in org.eclipse.ui bereitgestellt. Sie ist folgendermaßen strukturiert:
- Workbench und Workbench-Fenster
Hauptfenster von Eclipse RCP-Anwendungen werden als Workbench Window bezeichnet. Der grundlegende Aufbau dieses Fensters ist durch Eclipse RCP vorgegeben und wird durch die Anwendungs-Plug-ins lediglich erweitert bzw. befüllt.
- Workbench-Page
Der Innenbereich eines Workbench-Fensters wird als Page bezeichnet. Jedes Workbench-Fenster hat genau eine Page:
- Views
Die Inhalte im Workbench-Fenster werden über Reiterkarteien strukturiert. Diese werden als Workbench-Parts bezeichnet. Views bzw. ViewParts sind Reiter, die in der Regel nur einmal geöffnet sein können:
- Perspektiven
Eine Perspektive beschreibt eine mögliche Anordnung der View-Parts in der Workbench-Page. Der Benutzer kann über die Perspektiv-Bar zwischen verschiedenen Perspektiven hin- und herwechseln:
Meist stellt eine Perspektive dem Anwender eine bestimmte Sicht auf die Anwendung bereit. Typisch sind Perspektiven für Tätigkeiten oder Aufgaben, beispielsweise eine Perspektive “Adresserfassung” oder “Mahnungen schreiben” - die Perspektive enthält dann alle Reiter, die für diesen Vorgang benötigt werden.
Standardmäßig kann die Anordnung und die Auswahl der Reiter einer Perspektive vom Benutzer verändert werden. Er kann bspw. die Größe verändern, die Reiterstruktur umgruppieren, Reiter minimieren oder maximieren.
- Editierbereich und Editoren
Neben Views gibt es eine zweite Art von Workbench-Reitern: Editoren. Editoren repräsentieren Dokumente, die der Benutzer öffnen, bearbeiten und wieder speichern kann. Editoren werden immer im Editierbereich (Editor Area) der Anwendung angezeigt, den alle Perspektiven gemeinsam haben:
- Toolbars und Statusbar
Sofern sie nicht ausgeblendet werden, hat jede RCP-Anwendung einen CoolBar-Bereich, in dem einzelne Toolbars angezeigt werden, sowie eine Status-Leiste:
Advisor-Klassen
Die Advisor-Klassen sind dafür zuständig, die Workbench im Rahmen des Startprozesses der Anwendung zu konfigurieren. Der Eintrittspunkt in diesen Mechanismus ist der createAndRunWorkbench-Aufruf in Ihrer Applikationsklasse:
Mittels des WorkbenchAdvisors konfigurieren Sie Einstellungen, die für die gesamte Workbench gelten. Der WorkbenchWindowAdvisor ist dafür zuständig, ein einzelnes Workbench-Fenster zu konfigurieren. Der ActionBarAdvisor erledigt die initiale Befüllung der Menüs und Toolbars der Anwendung.
Views contributen
View-Reiter werden der Workbench über den Extension Point org.eclipse.ui.views bekannt gemacht. Dabei ist eine eindeutige ID, der Name sowie eine implementierende Klasse für das View anzugeben:
<extension point="org.eclipse.ui.views">
<view
id="com.example.someView"
class="com.example.SomeViewPart"
name="SWT Tests">
</view>
</extension>
Die implementierende Klasse erbt von ViewPart und ist mit der Methode createPartControl vor allem dafür zuständig, den View-Reiter mit Inhalten zu befüllen:
public class SomeViewPart extends ViewPart {
@Override
public void createPartControl(Composite parent) {
// View-Inhalte werden hier erzeugt
}
@Override
public void setFocus() {
// Dem ersten Control sollte hier der Focus gegeben werden
}
}
Perspektiven contributen
Perspektiven werden der Workbench über den Extension Point org.eclipse.ui.perspectives bekannt gegeben. Analog zu Views ist eine ID, Name und implementierende Klasse anzugeben:
<extension point="org.eclipse.ui.perspectives">
<perspective
id="com.example.addressbook.somePerspective"
name="Some Perspective"
class="com.example.addressbook.SomePerspective"/>
</extension>
Die Klasse muss IPerspectiveFactory implementieren und ist dafür zuständig, die initialen Inhalte und Anordnung der Reiter festzulegen. Dazu bekommt sie eine IPageLayout-Instanz, mit der sie das Layout für die Perspektive konfigurieren kann:
public class SomePerspective implements IPerspectiveFactory {
public void createInitialLayout(IPageLayout layout) {
// Configure perspective layout here
}
}
Views zu Perspektiven hinzufügen
Um einer Perspektive ein View hinzuzufügen, verwenden Sie in der PerspectiveFactory die Methode IPageLayout.addView:
addView(String viewId, int relationship, float ratio, String refId)
Das neue View wird gem. relationship links/rechts/oberhalb/unterhalb zu refId angeordnet und erhält ratio Prozent der verfügbaren Gesamtbreite bzw. -höhe. Als refId können Sie die ID eines anderen Views angeben oder IPageLayout.getEditorArea() verwenden, um relativ zum zentralen Editierbereich zu stehen.
Beispielsweise würden ein View folgendermaßen mit 30% der Gesamthöhe überhalb des Editierbereiches angeordnet werden:
layout.addView(SomePluginConstants.SOME_VIEW_ID, IPageLayout.TOP, 0.3f, layout.getEditorArea());
View-Reiter innerhalb einer Perspektive gruppieren
Innerhalb einer Perspektive können Sie Views mittels eines Folders gruppieren. Verwenden Sie dazu createFolder:
public void createInitialLayout(IPageLayout layout) {
IFolderLayout folder = layout.createFolder("com.example.somefolder",
IPageLayout.TOP, 0.4f, layout.getEditorArea());
folder.addView(SomeViewPart.VIEW_ID);
folder.addView(SomeOtherViewPart.VIEW_ID);
}
Initiale Perspektive festlegen
Beim Erzeugen der Workbench bestimmt der WorkbenchAdvisor Ihrer Anwendung die initial anzuzeigende Perspektive:
public class ApplicationWorkbenchAdvisor extends WorkbenchAdvisor {
public String getInitialWindowPerspectiveId() {
return SomePluginConstants.SOME_PERSPECTIVE_ID;
}
}
Perspektiv-Bar einblenden
Die Perspektiv-Bar, mit der der Benutzer die Perspektive zur Laufzeit wechseln kann, können Sie über den WorkbenchWindowAdvisor Ihrer Anwendung sichtbar machen:
public class ApplicationWorkbenchWindowAdvisor extends WorkbenchWindowAdvisor {
public void preWindowOpen() {
IWorkbenchWindowConfigurer configurer = getWindowConfigurer();
// ...
configurer.setShowPerspectiveBar(true);
// ...
}
}
Best Practices: Umgang mit IDs
IDs für Workbench-Elemente wie Views und Perspektiven sollten eindeutig und aussagekräftig gewählt werden. Da sich Entwickler, die Erweiterungen zu Plug-ins schreiben, häufig auf solche IDs beziehen, ist es unter Umständen schwierig, diese IDs nachträglich zu ändern.
Es empfiehlt sich, für IDs Konstanten in einer gesonderten Klasse in einem exportiertem Package anzubieten. So können andere Plug-ins im Code darauf Bezug nehmen und die implementierenden Klassen können intern bleiben. Beispielsweise:
package com.example.someplugin;
public class SomePluginConstants {
public static final String SOME_VIEW_ID = "com.example.someview";
public static final String SOME_PERSPECTIVE_ID = "com.example.someperspective";
}



Es sind wirklich gute Erklärungen, was ich vermisse sind die Eclipse screenshots aus dem vorhergehenden Kapiteln.