GEF-Tutorial Kapitel 4
Aus Wirthi's Wiki
| GEF-Tutorial Eclipse Graphical Editor Framework |
|---|
| Allgemeines Kapitel 1 (Überblick) Kapitel 2 (Model-View-Controller) Kapitel 3 (Model) Kapitel 4 (Controller) Kapitel 5 (View) Kapitel 6 (Editor-Hauptklasse) Kapitel 7 (Einsatz und Zusammenfassung) |
Im Kapitel 4 des GEF-Tutorials wird der Controller-Teil der MVC-Architektur eines GEF-Editors beschrieben.
[bearbeiten] Aufgaben
Der Controller verbindet Model- und View-Objekte des Editors. Im Normalfall existiert für jedes Model-Objekt auch genau ein Controller-Objekt. Dieses ist wiederum mit genau einem View-Objekt verbunden. Vom Model-Objekt empfängt der Controller Änderungs-Notifikationen und kümmert sich um gegebenenfalls notwendige Änderungen der Darstellung des View-Objektes.
Eine weitere Aufgabe des Controllers ist die Verarbeitung von Benutzereingaben. Sämtliche Interaktionen des Benutzers (etwa Maus- und Tastaturaktionen), die ein View-Objekt des Editors betreffen, werden an das jeweilige Controller-Objekt weitergeleitet. Hält dieses die Eingabe für relevant, kümmert es sich um die entsprechende Änderung des Model-Objektes. Die Aktualisierung der Anzeige geschieht anschließend auf dem oben beschriebenen Weg, durch eine Änderungs-Notifikation des Model-Objektes und die anschließende Aktualisierung der View-Klasse durch den Controller.
Der hier beschriebene perfekte Gleichklang zwischen Model, View und Controler stellt den Idealzustand dar. In der Praxis Muss es nicht unbedingt sein, dass jedes Model-Objekt genau ein Controller-Objekt hat, das wiederum genau ein View-Objekt verwaltet. Im aktuellen Zustand nicht sichtbare Model-Objekt etwa haben meist auch keinen Controller und keine View. Auch kann es sein, dass ein Model-Objekt gleichzeitig mehrfach angezeigt wird; dann existieren für ein Model-Objekt zwei (oder mehr) Controller-Objekte und entsprechende Views.
[bearbeiten] Implementierung
Controller-Klassen müssen das Interface org.eclipse.gef.EditPart implementieren (in der Folge wird oft der Begriff EditPart verwendet werden, wenn Controller gemeint ist; das ist die von GEF verwendete Bezeichnung). Meist wird dies durch Ableiten der Controller-Classe von org.eclipse.gef.editparts.AbstractGraphicalEditPart erledigt. Diese Klasse implementiert die Funktionalität des Interfaces bereits mit einer Standardfunktionalität. Auf diese Weise spart man sich einiges an Arbeit und braucht nur die Methoden selber überschreiben, die man im aktuellen Kontext benötigt.
Typischerweise von AbstractGraphicalEditPart überschriebene Methoden sind:
- der Konstruktor
- createFigure
- createEditPolicies
- refreshVisuals
[bearbeiten] Konstruktor
Im Konstruktor wird die Initialisierung der Klasse vorgenommen. Dem Konstruktor wird das verwaltete Model-Objekt übergeben; dieses wird also in einer Membervariablen abgespeichert. Diese Variable und die Zugriffsfunktionen sind vom Framework bereits implementiert; das Model-Objekt braucht nur mehr mit setModel(Object) gespeichert werden.
Ansonsten sind meist keine weiteren Daten vorhanden, die initalisiert werden müssen; der Status der Daten ist ohnehin im Model verpackt.
public SampleEditPart(SampleModel modelObject) {
setModel(modelObject);
}
[bearbeiten] createFigure
Die Funktion createFigure() wird vom Framework aufgerufen, damit der EditPart ein View-Objekt anlegt und dieses zurück gibt. Die View muss das Interface IFigure implementieren; ein Objekt von diesem Typ wird auch als Rückgabe erwartet. Der EditPart legt also in dieser Funktion ein korrespondierendes View-Objekt an und gibt es zurück:
protected IFigure createFigure() {
return new SampleView();
}
[bearbeiten] createEditPolicies
Weiter oben wurde bereits erwähnt, dass EditParts für die Verarbeitung von Benutzereingaben zuständig sind. Tatsächlich definieren die EditParts nur, welche Eingaben auf das jeweilige Model-Objekt erlaubt sind. Die tatsächliche Verarbeitung geschieht durch sogenannte EditPolices. Der EditPart kann in der Funktion createEditPolicies die von ihm gewünschten Policies anlegen und damit auf die jeweiligen Aktionen reagieren.
Die Funktion muss zwar implementiert werden, braucht aber im Minimalfall keinen Code enthalten. Der Editor reagiert dann nicht auf Benutzereingaben auf das Objekt.
protected void createEditPolicies() {
}
[bearbeiten] refreshVisuals
Die Funktion refreshVisuals wird vom Framework aufgerufen, wenn die visuelle Darstellung der View zu aktualisieren ist. Dies ist einerseits nach dem Anlegen des EditParts der Fall, andererseits immer dann, wenn das Model-Objekt verändert wurde. Der erste Fall ist im Framework bereits implementiert; der Aufruf von refreshVisuals bei Änderungen im Model ist hingegen selber zu ergänzen!
Wie die View aktualisiert wird, schreibt das Framework nicht vor. Eine mögliche Lösung ist, dass die View eine Methode zur Verfügung stellt, die die Aktualisierung der View erlaubt. Hier wird dieser Weg gewählt. Er hat den Vorteil, dass die View keine Daten des Models speichert und nur bei (und während) des Aufrufs dieser update-Funktion Zugriff auf das Model-Objekt hat.
protected void refreshVisuals() {
SampleView view = (SampleView)getFigure();
view.update((SampleModel)getModel());
}
Die von AbstractGraphicalEditPart geerbte Funktion getFigure liefert die von createFigure angelegte View zurück, getModel() das vom EditPart kontrollierte Model-Objekt.
| GEF-Tutorial: Allgemeines - Kapitel 1 - Kapitel 2 - Kapitel 3 - Kapitel 4 - Kapitel 5 - Kapitel 6 - Kapitel 7 |
