Um die Entstehung des Workbench-Modells in e4 zu verstehen, ist es nützlich, sich vor Augen zu führen, wie eine klassische Eclipse-3.x-Anwendung erstellt wird. Egal, ob IDE oder RCP, die Anwendung besteht immer aus einer Reihe von so genannten Contributions (Views, Editors, Commands usw.), die von der Eclipse-Plattform zur Laufzeit zu einem großen Ganzen zusammengeführt werden. Die Contributions werden in plugin.xml-Dateien definiert, wobei jede Contribution (auch Extension genannt), im Prinzip nichts anderes ist als ein XML-Schnipsel in einem bestimmten Format. Das Schema für solche Schnipsel wird jeweils pro Extension Point in einem .exsd-File definiert, und die Schnipsel nehmen über ID-Attribute aufeinander Bezug. Die Plattform verwaltet diese Contributions zur Laufzeit in separaten Registries (z. B. ViewRegistry, EditorRegistry, …) und wandelt dazu die im .exsd-Schema vorliegenden Daten in Java-Objekte um, die in der Regel „Deskriptoren“ genannt werden (IViewDescriptor, IEditorDescriptor …). Dieser Ansatz bringt jedoch einige Nachteile mit sich:
- Das Modell ist starr und nur mit hohem Aufwand manuell erweiterbar.
- Es wird davon ausgegangen, dass die Applikation Dateien ausschließlich aus deklarativen Contributions in plugin.xml bildet und z. B. ein programmatorisches Erzeugen der Applikation nicht zulässt.
- Das Modell zerfällt in mehrere, unverbundene Teile. Es gibt keine zentrale Instanz, an der ein Anwendungsentwickler modellweite Anpassungen vornehmen kann, um z. B. einen anderen Persistenzmechanismus zu verwenden, oder an zentraler Stelle Contributions zu filtern.
- Als Anwendungsentwickler kann man sich nur durch Starten der Anwendung ein Gesamtbild machen, und das auch nur unter der Voraussetzung, dass man keine Fehler gemacht hat, wie z. B. den typischen Fehler von IDs, die nicht zu 100 % übereinstimmen.
Zusätzlich zu den Registries gibt es noch weitere, dem Entwickler mehr oder weniger komplett verborgene Zustandsinformationen. Neben verschiedenen Quellen solcher Informationen, wie die diversen Advisor-APIs (z. B. ActionBarAdvisor, WorkbenchWindowAdvisor), PerspectiveFactories und das Presentation API, gibt es auch noch die tatsächliche Information über den momentanen Zustand aller Workbench-Fenster, inklusive deren Position und Größe, aktueller Perspektive, welche Views und Editoren geöffnet sind, deren visuelle Anordnung und so weiter. Erst die Gesamtheit dieser Informationen lässt die typische Eclipse-Oberfläche entstehen.
Manche Informationen sind sogar nur über das resultierende UI selbst abfragbar, wie z. B. im ActionBarAdvisor erzeugte Actions. Als Resultat gibt es nicht nur keine Möglichkeit, sich ohne Starten der Anwendung ein Gesamtbild zu machen, es ist auch praktisch unmöglich, die einzelnen Modelldaten auszulesen, zu verarbeiten und zu verändern.
Das e4-Workbench-Modell
Das e4-Projekt verfolgt einen integrativen Ansatz, indem es einer e4-Applikation ein zentrales Applikationsmodell zugrunde legt, das sowohl UI-Strukturen (Applikationsfenster, Menüeinträge, etc.) als auch nicht-visuelle Aspekte der Workbench, wie Kommandos und ihre dazugehörigen Handler in sich aufnimmt und verwaltet. Dem Anwendungsentwickler steht also eine zentrale Stelle zur Verfügung, in der er die Struktur seiner Applikation einsehen und darüber auch direkt beeinflussen kann – mehr dazu später im Kapitel über das Rendering. Abbildung 1 zeigt eine Modellinstanz einer laufenden e4-Applikation. Anhand dieses Beispiels identifizieren wir zunächst die Grundbauelemente und gehen auf einige von ihnen im Einzelnen ein.
Im Workbench-Modell finden sich folgende UI-Elemente:
- Window
- Window Trim
- Part Sash Container
- Menu und MenuItem
- Part und SaveablePart
Und außerdem nicht-visuelle Elemente:
- Key Binding
- Command
- Handler
Dem geschulten Auge dürfte in Abbildung 1 nicht entgangen sein, dass in e4 nicht ein JavaBean, POJO oder selbst geschriebenes Domain-Modell-Framework verwendet wird, sondern ein EMF-Modell. Das Eclipse Modeling Framework bringt viele Features mit sich, die für e4 wichtig sind:
- Serialisierung und Deserialisierung der Objektgraphen
- Eventsystem, das über Zustandsänderungen im Domain-Modell informiert
- Codegeneratoren, um die Java-Sourcen automatisch zu erzeugen
- Wohldefinierte Möglichkeiten, das Domain-Modell einfach zu erweitern
Ein weiterer wichtiger Grund ist das von EMF angebotene Tooling rund um Domain-Modelle, das sich bei Weitem nicht auf Editier- und Visualisierungstools beschränkt. Außerdem bietet sich so für e4 eine Verbindung zur starken und innovativen EMF-Community. Erste Synergieeffekte sind schon zu beobachten – z. B. arbeiten Xtext-Committer an einer e4-spezifischen, domänenspezifischen Sprache (DSL), mit der man eine e4-Applikation textuell definieren kann, und es wurde prototypisch gezeigt, dass man mithilfe von CDO das e4-Applikationsmodell zwischen verschiedenen JVMs synchronisieren kann.
