Eclipse Community Forums: Graphiti » Customized Editing Domain for Diagram Editor

Home » Modeling » Graphiti » Customized Editing Domain for Diagram Editor(Method dispose removes a shared command stack)

Show: Today's Messages :: Show Polls :: Message Navigator

Customized Editing Domain for Diagram Editor [message #766019]

Thu, 15 December 2011 04:42

Kunal Prasad

Messages: 18
Registered: September 2009

Junior Member

Hi,
I wish to use a shared Transactional Editing Domain for Diagram Editor of Graphiti. The editing domain is created by external component like project explorer view. Now when a new diagram is opened for the first time, it works fine since I have overridden its init method to pass DiagramInput with my own editing domain.

The problem happens when the editor is closed. In the dispose method of 'DiagramEditorInternal', the dispose method sets the command stack of the editing domain to null. This creates a NPE when the editor is reopened for same or another diagram file.

To solve it I overridden the dispose method of 'DiagramEditorInternal' into a new derived class and used that editor class for opening the diagram file. But due to restriction, I couldn't set some of its fields like behavior, paletteRoot etc to null, which leaks memory.

So please suggest a better way to handle the case of using a shared editing domain for the diagram.

Thanks,
Kunal

Report message to a moderator

Re: Customized Editing Domain for Diagram Editor [message #778129 is a reply to message #766019]

Wed, 11 January 2012 12:59

Veit Hoffmann

Messages: 20
Registered: July 2009

Junior Member

Am 15.12.2011 05:42, schrieb Kunal:
> I wish to use a shared Transactional Editing Domain for Diagram Editor
> of Graphiti. The editing domain is created by external component like
> project explorer view. Now when a new diagram is opened for the first
> time, it works fine since I have overridden its init method to pass
> DiagramInput with my own editing domain.

Hi, I had the same problem too. I have an editor with several
DrillDownFeatures that open diagrams on subelements of the model. E.g. a
use case diagram that contains activity-diagrams within the use cases.
All these Editors habe to share the same EditingDomain to prevent merge
conflicts in the Buisinessmodel-Resource.
I implemented this by overwriting the DrilldownFeature like this

MyDrillDownFeature extends AbstractDrillDownFeature {
...
@Override
protected void openDiagramEditor(Diagram diagram) {
// Found a diagram to open
String diagramTypeProviderId =
GraphitiUi.getExtensionManager().getDiagramTypeProviderId(diagram.getDiagramTypeId());
GraphitiUiInternal.getWorkbenchService().openDiagramEditor(diagram,
getTransActionalEditingDomainForNewDiagram(),
diagramTypeProviderId, getDiagramEditorId(diagram), false);
// here the last parameters prevents the disposal of the editing domain
on close
}

@Override
protected TransactionalEditingDomain
getTransActionalEditingDomainForNewDiagram() {
// share the editing domain
return getDiagramEditor().getEditingDomain();
}
}

However this approach assumes that the "parent"-Editor -in the example
the use case editor- is closed last. Else you will run into the same
problem because the "parent"-Editor disposes the EditingDomain by default.

You could work around this by forcing this editor also not dispose the
editing domain.
E.g. by overwriting the setInput method of the editor like this:

@Override
protected void setInput(IEditorInput input) {
if (input instanceof DiagramEditorInput) {
super.setInput(DiagramEditorInput.createEditorInput(
diagramEditorInput.getDiagram(),
(TransactionalEditingDomain)
diagramEditorInput.getAdapter(TransactionalEditingDomain.class);
initializeEditingDomain(adapter);,
diagramEditorInput.getProviderId(), false));
}
super.setInput(input);

}

But in this case you need to handle the disposal of the EditingDomain
when the last Editor is closed by hand. E.g. with a Singleton that keeps
track of registered editors or by subclassing TransactionalEditingDomain.

If you want to keep one editing domain open the whole time while your
application is running you can also use the second approach too.

Cheers Veit

Report message to a moderator

Re: Customized Editing Domain for Diagram Editor [message #892033 is a reply to message #778129]

Tue, 26 June 2012 22:47

Josef Pohl

Messages: 82
Registered: January 2012

Member

Hi Veit and Kunal, (and everyone else... as always)

Sorry to drag up an old post like this but from all appearances you seem to have had success with similar issues to what I am dealing with trying to replicate drill-down behavior. In my case I am still trying to make an initial association between two diagrams that is stable (My toils can be found here.)

The scenario I am trying to implement is as follows:
From an initial diagram with a feature (Ai)
Open a new diagram
Copy Ai to a new feature An on the new diagram
Ai and An are represented by the same underlying model element (which is in a resource separate from the diagram).

I was wondering, even though you do not (seem to) have an initial element that is linked between the two diagrams, how do you make the initial association between the two diagrams?

Can you give a bit more detail on the setInput method (where exactly are you overriding this?) and the Singleton to keep track of editors you mention to control the "close parent editor last" issue?

Thanks in advance,

Joe

Report message to a moderator

Previous Topic:	recommended way to group updates?
Next Topic:	Graphiti Editor in a custom Editor

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Apr 23 15:00:19 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter