Erzeugung des Workbench-Modells
Wie beim Blick auf Eclipse 3.x schon kurz angesprochen wurde, ist die Verwendung von plugin.xml-Elementen zwingend vorgeschrieben, dem Benutzer bleibt also keine Wahl. Einer e4-Applikation ist es hingegen eigentlich egal, wie das Applikationsmodell entsteht.Die erste Standardmöglichkeit ist, das Modell mithilfe des Standard-EMF-Toolings (Abb. 1) zu definieren und die entstandene Datei als ein Attribut im OSGi-Produkt-Extension-Point zu übergeben (Abb. 3). Diese Möglichkeit wird wahrscheinlich oft bei RCP-Applikationen gewählt werden, weil dort in der Regel eine relativ ausführliche Grundstruktur feststeht und später nur noch erweitert wird.
Die zweite Standardmöglichkeit fängt mit einem relativ schlanken Grundmodell an und erweitert dieses ähnlich wie in Eclipse 3.x um Contributions. Diese Erweiterung geschieht über den Extension Point org.eclipse.e4.workbench.model. Dieser erlaubt es dem Entwickler (im aktuellen Stand), alle Typen von Modellelementen als XMI-Snippets in das e4-Applikationsmodell einzubringen (Abb. 4 und 5). Dabei ist es durchaus möglich und erwünscht, dass logisch zusammenhängende Contributions innerhalb eines solchen Snippets definiert und als Ganzes in das Grundmodell eingefügt werden.
Die Übersetzung des Modells in ein UI
Abbildung 6 zeigt das Grunddesign für die Übersetzung des Workbench-Modells in ein UI. Die Grundidee ist, dass der e4-Applikationscontainer sich nicht selbst um die Übersetzung des Applikationsmodells in eine Oberfläche kümmert, sondern das an ein IPresentationEngine genannten Service delegiert und damit selbst keine Abhängigkeiten auf Oberflächentechnologien hat. Die Schnittstelle zum IPresentationEngine-Service ist zurzeit ganze fünf Methoden schlank.
Die Standard-IPresentationEngine in e4 verwendet SWT und setzt das Standardaussehen von e4 um. Diese PresentationEngine arbeitet im Prinzip so, dass für jedes UI-Element im Applikationsmodell zumindest ein zuständiger so genannter Renderer existieren muss (Abb. 7).
Die erste Aufgabe dieses Renderers ist, ein konkretes UI-Widget zu erzeugen und es am Ende, wenn es nicht mehr gebraucht wird, auch wieder zu zerstören. Die zweite Aufgabe ist es, die Attribute des erzeugten UI-Widgets und des entsprechenden Modellelements zu synchronisieren. Das gilt für einfache Attributsänderungen wie die Änderung eines Textattributs, aber auch für komplexe, wie das Verschieben eines Elements von einem zu einem anderen Elternteil.
Eine Auswirkung dieses Designs ist es aber auch, dass alle Änderungen, die in der Oberfläche angezeigt werden, immer über das Workbench-Modell gemacht werden können und müssen. Der Anwendungsentwickler kann nicht wissen, welches UI-Widget verwendet wird, um ein Modellelement darzustellen. Das ermöglicht einerseits, dass man mithilfe eines anwendungsspezifischen Renderers komplett andere Widgets verwenden kann und somit zusätzlich zu den von Kai Tödter bereits besprochenen CSS-Styling-Möglichkeiten [2] auch strukturell anderes Aussehen erreichen kann. Im Extremfall ist es sogar möglich (natürlich nicht ohne gewissen Aufwand), ein komplett anderes UI-Toolkit zu verwenden. Swing-Fans könnten also theoretisch das e4-Anwendungs- und Programmiermodell übernehmen, das UI aber vollständig in Swing implementieren.
Zusammenfassung
Die Stärke von e4 ist die zugrunde liegende Philosophie lose gekoppelter Teile, wovon die klare Trennung zwischen Applikationsmodell und Präsentationsschicht ein Beispiel ist. Wir haben die Vorteile des EMF-basierenden Modells aufgeführt und beschrieben, wie das Modell durch austauschbare Renderer mit der Präsentationsschicht synchronisiert wird. Aus unserer Sicht ist e4 besonders für RCP-Entwickler interessant. Die neue Eclipse-Plattform bietet Flexibilität und Freiheiten, die es ermöglichen, e4-Applikationen zu erstellen, die auf dem mittlerweile umkämpften Rich-Client-Markt gegen Konkurrenten bestehen können.
