Skip to main content

Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Graphiti » Diagram Editor and its API
Diagram Editor and its API [message #758969] Fri, 25 November 2011 12:16 Go to next message
Michael Wenz is currently offline Michael WenzFriend
Messages: 1921
Registered: July 2009
Location: Walldorf, Germany
Senior Member

we are going to work on introducing an official API for the diagram editor,
as it turned out that many clients will need to override DiagramEditor to
achieve desired behaviour. This is tangled in Bugzilla 336488
( Some discussions
have already been made in there.

This is a call to all users of Graphiti: please let us know if you have an
requirements, needs, wishes or things you would like to have considered
while we create that API please let us know. Either in this forum entry or
in the bugzilla.

This will not be limited to the classes DiagramEditor and
DiagramEditorInternal only, but also other surrounding classes like
DiagramEditorBehaviour, the editor input, factory, listeners in the editor
will be affected by this.

Re: Diagram Editor and its API [message #758999 is a reply to message #758969] Fri, 25 November 2011 14:38 Go to previous message
Hernan Gonzalez is currently offline Hernan GonzalezFriend
Messages: 188
Registered: October 2010
Location: Buenos Aires, Argentina
Senior Member
To begin the discussion, I propose the following:

- Decouple DiagramEditor and DiagramEditorBehavior (the later could have a more apt name, but I don't think that's important... and it's difficult to get a good name Razz ) so that they have different responsabilities, different extensibility, and a clear joint lifecycle and a set of methods to communicate between them. Specifically:

- DiagramEditor (actually DiagramEditorInternal) is related to the core Graphiti editor functionality, it talks with Graphiti core things and with GEF/Draw2D. DiagramEditorBehavior has nothing to do with GEF and Graphiti core, its only responsability is to provide the main object that the DiagramEditor manipulates ( the Diagram itself, and the EMF domain), taking care of persistence (load/save) and detecting changes to the underlying resources provoked by actions outside the Editor (in the Eclipse Resources world, or perhaps in the EMF Resources world)

- DiagramEditorBehavior (abbreviate: DEB) can be fully extended or fully reimplemented by the user. It
provides to the DiagramEditor a simple interface, for example (this needes more thought) :

	 * Loads the diagram (typically delegating on the diagram provider), 
	 * If the loading is successfull, the listeners will be registered
	 * and the object will be ready for use.
	 * In case of error an exception will be thrown - and this object should be
	 * discarded by the caller.
         * The domain should be used if not null, elsewhere a new domain should be created.
	 * The editor will call this method only at initialization (init)
	 * but the object might call it internally for diagram reloading, if supported.
	public abstract void loadDiagram(IEditorInput input, TransactionalEditingDomain domain);

	 * This is for implementing {@link IEditorPart} and simply saves the model file.
	 * @param progressMonitor
	 *            The {@link IProgressMonitor} progress monitor
	public abstract void doSave(IProgressMonitor progressMonitor);

	 * Unregisters listeners and dispose domain (if it should)
	 * The object should not be usable after this is called. 
	public void dispose();

	 * Returns null only if the diagram is still not loaded or if it's disposed
	public Diagram getDiagram();

	public TransactionalEditingDomain getEditingDomain();

- DiagramEditor will never try to access its EditorInput to deduce if the diagram is loaded, etc (as today), it never assumes anything about the underlying persistence model used. The same for Graphiti services.
Goal: all things should work untouched if, for example, the user wants to use a diagram-model saved in different files, or a model-only scenario (with Diagram creation on loading). The only thing for him to change is the DEB.

- DiagramEditorInput is gone. The IEditorInput that is passed to the DEB at loading can be antyghing (tipically it will be a FileEditorInput. But it's DEB responsability to understand it and to know if it corresponds to a Diagram or to a model or what. The DiagramEditor just doesn't know.

- Lifecycle: DiagramEditor and have the same lifecycle as its DEB: they live as long as the editor.
The Editor creates its companion DEB instance at construction time by calling a factory method (createDiagramEditorBehavior()) which the user can extend. (Graphiti can provide its default GEB, perhaps more than one). The EMF domain, stored in the DEB, has the same lifecycle (it can't change), but the Diagram can change (can be reloaded) as also the editorInput. (We could put the restriction that a given DiagramEditor instance can't reload a Diagram that has a different diagramTypeId)

- It's OK that the user extends DiagramEditor, but only to provide his own DiagramEditorBehaviour... and to extend some other methods which might

All of this is just tentative suggestion - I have something along this lines working, in the model-only scenario, but not yet fully.
Previous Topic:Making sense of listeners in DiagramEditor
Next Topic:How to use Drag&Drop Feature?
Goto Forum:

Current Time: Tue Aug 04 19:03:59 GMT 2020

Powered by FUDForum. Page generated in 0.02471 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top