Previous: 4. Implementierung Up: 4. Implementierung Next: 4.2 Implementierung des GUI-Modells
Jedes Plug-in für Eclipse muss eine Spezialisierung der Klasse Plugin anbieten. Plug-ins, die sich zudem in die graphische Oberfläche der Eclipse-Plattform integrieren möchten, sollten die für diese Zwecke weiter spezialisierte Klasse AbstractUIPlugin erweitern. Die Klasse GuiBuilderPlugin ist eine solche Unterklasse von AbstractUIPlugin und repräsentiert damit das Plug-in von GuiBuilder innerhalb des Eclipse-Systems (siehe Abb. 4.1).
Wird auf Funktionalitäten des Plug-ins das erste Mal zugegriffen, zum Beispiel indem eine .gui-Datei geöffnet werden soll, so wird von Eclipse automatisch eine Instanz dieser Klasse erzeugt. Diese wird vom Eclipse-System durch Methodenaufrufe über den Lebenszyklus des Plug-ins auf dem Laufenden gehalten und stellt zudem einige rudimentäre Funktionalitäten zur Verfügung, die zum Beispiel die Möglichkeit bieten, Dialog-Einstellungen oder Grundeinstellungen permanent im Eclipse-System für das Plug-in abzuspeichern.
In den Hilfsklassen Messages, Images und Keys werden jeweils zentral Textnachrichten, Bilder und Tastaturkürzel bereitgehalten. Die Textnachrichten (Messages) werden dabei mithilfe der von GuiBuilderPlugin angebotenen Funktionen zur Ressourcen-Ermittlung aus einer Datei geladen. Jede Nachricht, die in GuiBuilder dem Benutzer angezeigt wird, ist innerhalb des Programms durch einen internen Bezeicher substituiert, der erst zu Programmstart über die Message-Klasse mit dem aus der Datei geladenen String assoziiert wird. Auf diese Weise lässt sich GuiBuilder durch unterschiedliche Versionen der Datei, die lediglich aus Paaren von IDs und Textnachrichten besteht, leicht internationalisieren. Im Moment werden Dateien für die deutsche und englische Sprache angeboten. Analog verhält es sich mit Bildern, die sich über dieselbe Datei ebenfalls - wenn nötig - internationalisieren lassen.
Die Klasse Keys hält zentral alle die von GuiBuilder verwendeten Tastaturkürzel. Konflikte durch Doppelbelegungen lassen sich somit vermeiden und eine eventuell notwendige Umstrukturierung aufgrund von erweiterten Funktionalitäten, die ebenfalls mit Tastaturbefehlen assoziiert werden sollen, ist leicht getan.
Zentraler Punkt der vom Plug-in bereitgestellten Funktionalität ist der GuiEditor (Abb. 4.2). Der GUI-Editor ist im Eclipse-System für das Öffnen von .gui-Dateien registriert. Soll also eine .gui-Datei bearbeitet werden, so wird der GUI-Editor automatisch von Eclipse instanziert und über die zu öffnende Datei (Ressource) informiert. Beim GUI-Editor handelt es sich um einen sogenannten Multi-Page-Editor. Als solcher besteht der GUI-Editor aus mehreren Seiten (Fenstern), zwischen denen gewechselt werden kann. Jedes Fenster besitzt dabei seinen eigenen Editor. Die Verwaltung dieser Editoren (NestedEditor) wird vom GUI-Editor übernommen. Er ist in der Lage, neue Fenster mit den entsprechenden Editoren zu erzeugen und auch wieder zu schließen.
Im GUI-Editor gibt es zwei verschiedene Arten von Fenstern und damit zwei verschiedene Arten von Editoren: Statechart-Fenster, in denen Statecharts erzeugt und bearbeitet werden können und die durch einen StatechartEditor verwaltet werden, und Layout-Fenster, für die Bearbeitung von Layouts, die mithilfe eines LayoutEditor realisiert werden. Beide Editoren sind Spezialisierungen von NestedEditor, deren Verwaltung der GUI-Editor übernehmen kann. Da verschiedene Ausschnitte eines Statecharts in neuen Statechart-Fenstern angezeigt werden können, ändert sich die Anzahl der Fenster und damit die Anzahl der verwalteten NestedEditor im Laufe der Editierung des GUI-Modells.
Jeder NestedEditor besitzt eine Werkzeugleiste (Palette), in der sich Werkzeuge zur Erstellung der jeweiligen Modell-Elemente befinden. Ein Statechart-Editor besitzt eine StatechartPalette mit Werkzeugen zur Erstellung von Statechart-Elementen, und ein Layout-Editor besitzt analog eine LayoutPalette.
Zur Editierung von Modell-Elementen werden neben den Möglichkeiten der graphischen Editierung mit Mausaktionen auch Abkürzungen mit Tastaturbefehlen angeboten und vor allen Dingen Funktionen über Kontextmenüs und Dialoge bereitgestellt. Dabei kommen zum einen von Eclipse angebotene Standarddialoge zum Einsatz und zum anderen Dialoge, die durch Spezialisierung von universell einsetzbaren Dialogmasken selbst mit SWT-Komponenten zusammengestellt wurden. Die Dialoge haben dabei jeweils das Look&Feel des benutzten Betriebssystems aufgrund der von SWT eingesetzten nativen Dialogelemente.
Der GUI-Editor, der das editierte GUI-Modell und die zugehörige Ressource verwaltet, lässt das Modell in dem von ihm erzeugten Validator validieren. Detaillierte Informationen über diesen Validierungsvorgang und das Feedback über die dort festgestellten Probleme geben wir in Abschnitt 4.3.
Zusätzlich zum GUI-Editor gibt es diverse Views, die verschiedene Ansichten auf das im GUI-Editor angezeigte GUI-Modell anbieten. Dazu gehört unter anderem der Problems-View, der die in der Validierung gefundenen Probleme gesammelt anzeigt.
Jeder im GUI-Editor eingebettete Editor stellt zudem einen Outline seines Inhalts zur Verfügung. Diese sogenannte Outline-Page wird für das jeweils im GUI-Editor ausgewählte Fenster im dafür vorgesehenen Outline-View angezeigt. Der Outline-View gehört wie auch der Problems-View zu den von Eclipse angebotenen Standard-Views. Das Eclipse-System fragt automatisch einen aktivierten Editor nach einer Outline-Page, die er im Outline-View anzeigen möchte. Diese Anfrage wird vom GUI-Editor als eine der von ihm übernommenen Verwaltungsaufgaben an den zur Zeit aktivierten NestedEditor weitergeleitet.
Analog sieht es bei dem Properties-View aus, welcher Eigenschaften eines selektierten Elements anzeigen kann. Wir verwenden den Properties-View, um Eigenschaften eines Modell-Elements, sei es ein Statechart-Element oder ein GUI-Element, anzuzeigen. Jedes Element, das Eigenschaften im Properties-View anzeigen möchte, propagiert diese mithilfe eines Interfaces. Die Eigenschaften werden im Properties-View in tabellarischer Form angezeigt und lassen sich dort sogar editieren. Eine Alternative zur Editierung von Properties stellt der Eigenschaften-Dialog dar, der für ein selektiertes Element über dessen Kontextmenü aufgerufen werden kann.
Der Layout-Preview ist in der Lage, eine Vorschau eines Layouts zu liefern. Beim Layout-Preview handelt es sich um keinen vom Eclipse-System standardmäßig angebotenen View. Er wird damit nur dann aktiv, wenn ein GUI-Editor im Eclipse-System aktiviert ist. Ist dies der Fall, so ermittelt der Layout-Preview über den GUI-Editor den derzeit aktiven NestedEditor und zeigt bei einem Layout-Editor eine Vorschau des in ihm bearbeiteten Layouts an oder er prüft bei einem Statechart-Editor, ob das gerade selektierte Element ein Layout bereitstellt (Layoutable).
Im Moment besitzen natürlich, wie im Modellierungskonzept festgehalten, ausschließlich Zustände (States) ein Layout. Um das Konzept aber zukunftssicher zu implementieren, wird die Bereitstellung eines Layouts durch das Interface Layoutable gekapselt (siehe Abb. 4.3).
Schließlich gibt es noch den Simulator-View, der mithilfe des GUI-Simulators, welcher vom GuiBuilderPlugin bereitgestellt wird, ein GUI-Modell simulieren kann. Dazu wird aus dem GUI-Editor heraus über eine Generierungsfunktion das GUI-Modell an den Simulator-View übergeben, der daraufhin die Simulation der GUI in die Wege leitet und den GUI-Editor bei dem von ihm dazu verwendeten GUI-Simulator als zu benachrichtigende Komponente registriert. Auf diese Weise wird der GUI-Editor über Zustandsänderungen informiert und kann entsprechendes Feedback in allen von ihm verwalteten Statechart-Editoren geben. Mehr zur Simulation von GUI-Modellen erfahren Sie in Abschnitt 4.4.
D. Hannwacker - A. Gebel - M. Dürksen 
