GMF: Lifecycle DiagramDocumentEditor bzw Editoren allgemein

[BjörnBu]

Hallo,

Ich möchte beim Öffnen einer Datei in einem Editor und beim Wechseln zu einem bereits geöffneten Editor (über die tabs im workbench) weitere Logik unterbringen. Genau genommen dreht es sich dabei um einen Editor der org.eclipse.gmf.runtime.diagram.ui.resources.editor.parts.DiagramDocumentEditor erweitert.
Da die grafischen Definitionen leider nicht immer aktuell sein müssen (z.B. wurde ein Verwandtes Artefakt aus'm svn ausgecheckt), muss ich genau da einschreiten.

Die Logik habe im im Großen und Ganzen (von dem anderen Artefakt aus lässt sich mit einer Action in aktuelles domain model und ein dazu passendes grafisches Model erstellen). Jetzt frage ich mich nur, wo der richtige Punkt ist, um das im Editor unter zu bringen, damit es beim Start und Aktivieren des Diagramm-Editor-Tabs

Irgendwie finde ich mich nicht so ganz zurecht was den Lifecycle eies Editors angeht. Gibt es da irgendwas, was mir weiterhelfen könnte? Ein Problem ist auf jeden Fall, dass ich eigentlich das ganze Verhalten von wegen hat sich die Resource geändert in der Zeit in der:
Mein Editor zu war (wohl das geringste Problem)
Mein Editor offen war und gespeichert hatte
Mein Editor offen war noch nicht-gespeicherte Änderungen hatte,
für eine weitere Resource zusätzlich zur diagram Resource nachbilden muss.

Mir ist klar, dass es deutlich angenehmer und sinnvoller wäre nur mit den richtigen GMF Modellen zu arbeiten und die anderen Artefakte entsprechend generieren zu können. Leider ist das gemäß der Anforderungen nicht möglich.

 

[Wildcard]

Du solltest entweder mit EditingDomains arbeiten die von mehreren Editoren (oder was auch immer) gleichzeitig verwendet werden. Wenn das aus Grund XY nicht funktioniert, sollte eigentlich ein WorkspaceChangeListener her.
Wenn auch das nicht geht (warum?) und du wirklich dabei bleiben willst, dann musst du wohl einen PartListener registrieren.

 

[BjörnBu]

Danke, werde zu den einzelnen Vorschlägen mal recherchieren. Mit EditingDomains habe ich bereits ich schönes Beispiel für die Integration der generierten EMF und GMF Editoren gesehen. Ich glaube aber, dass das nicht für meine Zwecke geeignet ist.

Aus meinem GMF/EMF modellen wird XML generiert, dass einerseits direkt in der Applikation genutzt wird, andererseits leider auch von allen Möglichen Ecken her geändert werden kann. Quasi aus dem svn ausgecheckt wird. Die grafischen odelle liegen nicht im svn (selbst wenn sie drin wären, so würde das XML möglicherweise auch von anderer Stelle aus geändert werden)

Ich werd emal schauen, ob ich den WorkspaceChangeListener da gebrauchen kann. Klingt zumindest vom Namen her ganz gut.

 

[BjörnBu]

Wäre es an sonsten denn möglich meinen GMF editor ohne diagram-file zu nutzen? Ich denke es wäre kein Problem auf das persistieren der Dartstellung zu verzichten und stattdessen nur auto arrange zu nutzen.

Ebenso würde ich dann auch auf das ecore modell file verzichten und mein von EObject abgeleitetes Root Element aus meiner eigenen Logik beziehen.

Mit dem bestehenden Domain Modell kann ruhig wieter gearbeitet werden. Auf das persistieren der Diagramelemente würde ich verzichten und mein Domain Modell eben in meiner XML-DSL und nicht in XMI ablegen. Geht das theoretisch? Je mehr ich über den anderen Ansatz nachdenke, desto sicherer bin ich mir, dass die Synchronisation inhaltlich nahezu redundanter Dateien irgendwie nicht die beste Lösung ist....

Leider scheinen die generierten Artefakte sehr eng mit den Persistentz-resourcen verknüpft zu sein.

Eine andere Möglichkeit wäre sehr simpel würde aber eigentlich alle Anforderungen abdecken:

Beim Öffnen eines Diagrams über das diagram file wird der ModificationStamp der beiden Resourcen verglichen und ist das XML neuer, wird eben das verwendet.

Beim performAsSave() wird wieder verglichen und ist das XML neuer, kann man wähen ob man das ausm Editor speichern will oder nicht.

Wäre das prinzipiell eine gescheite Vorgehensweise?