Zwiebelschalen
Zum Verständnis von GEF3D sind grundlegende Kenntnisse von GEF unerlässlich. Daher soll zunächst kurz auf ein paar Designmerkmale von GEF eingegangen werden, um dann zu beschreiben, wie diese eingesetzt werden können, um GEF 3D-fähig zu machen. Als Orientierungshilfe dient hierbei Abbildung 2, die die wichtigsten Klassen und Entwurfsmuster beider Frameworks in Form einer Zwiebelschale darstellt. Das Bild sieht auf den ersten Blick zwar etwas unübersichtlich aus, doch keine Angst: Die aufgeführten Elemente werden im Folgenden von innen nach außen beschrieben, und ich verspreche schon jetzt, dass es weniger kompliziert ist als es scheint.
Crashkurs GEF
Im Mittelpunkt von GEF steht das Model-View-Control-Pattern (MVC), in der Abbildung 2 entsprechend im Zentrum (hellblau) dargestellt. Im Fall von GEF handelt es sich um ein sehr feingranulares MVC, d. h. dass ein MVC-Tripel für jedes editierbare Element erforderlich ist, angefangen vom Diagramm über einzelne Knoten und Kanten bis hin zu Beschriftungen. Das "Model" stellt wie üblich die eigentlichen Daten bereit, GEF stellt keine besonderen Anforderungen an die Modellimplementierung. Häufig wird jedoch das Modell mit EMF [8] implementiert, beim Einsatz von GMF ist das sogar zwingend. Die "View" ist bei GEF in einer eigenen Bibliothek umgesetzt: Draw2D. Zur Darstellung einzelner Elemente werden so genannte Figures verwendet. Diese sind als Baum organisiert. Die RootFigure ist schließlich im LightweightSystem enthalten, einer Art Adapterklasse zwischen den Figures und dem SWT (der Eclipse-spezifischen Widget Bibliothek). Das LightweightSystem zeichnet die Figuren auf ein SWT-Canvas und leitet Ereignisse von SWT an GEF weiter. Für jedes editierbare Element muss ein eigener Controller bereitgestellt werden. Im GEF-Jargon heißt das EditPart. Im Fall grafischer Editoren ist das genauer ein GraphicalEditPart. Dieser erzeugt u. a. die Figure. Im Gegensatz zu anderen MVC-Implementierungen stehen bei GEF die EditParts klar im Zentrum des MVC-Tripels: Sie überwachen das Modell und steuern die Figures an. Eine Verbindung zwischen View und Model gibt es hier nicht. Wie die Figures sind auch die EditParts als Baum organisiert.Wir richten unseren Blick nun auf die zweite Zwiebelschale (blau), bleiben also noch ein wenig bei GEF. Mit dem LightweightSystem haben wir bereits einen kleinen Blick auf diese Schale riskiert, und wir wandern diese nun entgegen dem Uhrzeigersinn entlang. Dabei starten wir ganz rechts bei der EditPolicy. Die EditParts haben als Controller viele Aufgaben auszuführen, von der Selektion der Elemente über die Erzeugung von Elementen bis hin zu individuellen Funktionen konkreter Editoren. Damit am Ende keine gefürchteten "Monsterklassen" entstehen, wird das Policy-Pattern, auch unter dem Namen "Strategiepattern" bekannt, eingesetzt. Die Idee des Patterns ist, bestimmte Funktionalitäten nicht im EditPart selbst umzusetzen, sondern diese in eine Policy auszulagern. Die Policy wird beim EditPart "installiert" und bei Bedarf aufgerufen. Eine Begleiterscheinung dieses Patterns ist, dass das Verhalten der EditParts über die Policies dynamisch verändert werden kann, denn um beispielsweise neue Funktionen bereitzustellen, können einfach während der Laufzeit neue Policies bei einem EditPart registriert werden. Wir werden später ausgiebig davon Gebrauch machen. EditParts werden über das Factory-Pattern erzeugt, die Fabrik heißt hier EditPartFactory. Der Kreis schließt sich mit dem EditPartViewer, der alle Teile zusammenhält: Das LightweightSystem mit den Figures, die EditPartFactory sowie auch (in der Abbildung nicht dargestellt) die Wurzel des EditPart-Baums. Der Viewer selbst ist Teil des GraphicalEditors, der die Schnittstelle zur Eclipse-Plattform darstellt und dort als Editor registriert wird.
Mit dem MVC werden also bei GEF die Verantwortlichkeiten getrennt, insbesondere wird die Darstellung vom Inhalt abgekoppelt. Das Verhalten der Controller wird mit Policies dynamisch veränderbar. Erzeugt werden die Controller mittels einer Factory. Diese Eigenschaften schaffen die Voraussetzungen dafür, GEF dreidimensional zu machen.
