Sunday, October 25, 2009

GMFTools Part 2: Sharing an EditingDomain

In this blog, I will elaborate on how GMFTools facilitates to share the same instance of an EditingDomain across multiple diagram editors.

What is an EditingDomain?

In GMF, each diagram editor works on its own instance of a so called TransactionalEditingDomain. TransactionalEditingDomain is a concept from EMF Transaction. In GMF, it contains an EMF ResourceSet holding the diagram model, its semantic model and all referenced models as well as a command stack for undo/redo support. In addition, each editor registers a WorkspaceSynchronizer to its resource files, making sure external changes are synchronized with the editor's content.

Why share the EditingDomain?

In the default setup, problems occur if two editors operate on the same resources: If both editors change the same resource, saving one will overwrite the changes of the other. This situation already happens when you're using the Related Diagrams feature in the gmfmap model: On double click, it will open a new diagram that is saved in the same resource but in a different editing domain. As the original editor is still open, conflicts can arise quickly.

Another reason for sharing the editing domain is to save memory and performance, especially if you're working on big models with a couple of editors.

In many cases you might want to see changes immediately in all editors without having to save first, e.g. when your editors show different parts or aspects of the same model. GMF has already built-in support for that as it uses EMF's notification mechanism to synchronize the notation (diagram) model with the semantic model.

Consequences of sharing an EditingDomain

Sharing the editing domain across several editors has a number of consequences
  • The editors will also share the same command stack. Undo/redo becomes a global operation and can therefore affect other editors than the currently active one.
  • For reasons of simplicity, all editors should be saved synchronously, and they will all be either dirty or clean at the same time.
  • You should no longer dispose the editing domain when closing an editor. That means, to avoid memory leaks you need strategy for unloading unneeded resources.
  • The command stack will keep references to unloaded model elements, too, so you might want to have an garbage collecting strategy here as well or at least keep the command history short.
Solution in GMFTools

The solution in GMFTools is based on a WiKi page of GMF and a couple of newsgroup entries combined with our own experiences. It has been recently refactored to reenable the WorkspaceSynchronizer.

It comes in a number of aspectual template changes for the GMF code generator, an additional runtime plug-in and tool support for fixing the type registry, such that it is rather easy to consume even if you're not too familiar with the GMF runtime. Note that so far we have only been using it to generate plain diagram plug-ins, i.e. not for GMF's RCP generator.

The major changes are
  • Redirect all creation statements of an editing domain to a new utility class and the dispose statements to an unloading tool.
  • Make sure to use consistent element types.
  • The common behavior of all XXDocumentProvider.ResourceSetInfo has been extracted to avoid synchronization feedback loops.
If you're interested in the details have a look at the WiKi-page.

11 comments:

scratsh said...

Hi,

I tried last week to use GMFTools to share editing domain without success. Is there any change on this tool? I noticed that the wiki page was edited some hours ago but I can't point out what the changement are. Can you please point them out?

Thanks by advance

Jan Köhnlein said...

The most recent change was a refactoring of the ResourceSetInfo template to reenable the workspace synchronizer and extract common functionality into a runtime class.

Maybe you can contact me by email and describe your problem in detail.

scratsh said...

Thanks,

I retried to send you an e-mail to your itemis mail, can you confirm me that you received it? or give me another mail address.

James Roome said...

I wonder if you could take a moment to review this issue: http://code.google.com/p/gmftools/issues/detail?id=12

Jan Köhnlein said...

James -

thanks a lot for reporting. I'll have a look at that ASAP.

Regards
Jan

Jan Köhnlein said...

James-
your issue should be fixed now. Would you mind to verify?

Santi said...

Hi Jan, I'm trying to use the same editing domain for two editors. I've tried it with gmf tools and following gmftips.But I can't get it!
I think it's because of the code modifications. Can I write you an e-mail and describe my problem in detail?
I need to do it as soon as I can.
My mail is muaysanthai@gmail.com, write me if you can and I'll describe my problem ok? thanks

Santi said...

Hi Jan, I need to share editing domain with two editors. I've tried it with GMFTools and following GMFTips post, without success. I think my problem is that I don't know what methods must I refactor.
Can I write an e-mail to describein detail my problem? I need finish it as soon as possible. My mail is muaysanthai@gmail.com, please write me and I'll mail you back with my problem. A lot of thanks

emna said...

I'd like to share my Editing Domain bat I can’t find XXXDocumentProvider,where I can find it? I’d Like to modify this class but I haven't found it

minanoun said...

Hello,

I'd like to share my editing domain, the problem that I can’t find XXXDocumentProvider,where I can find it? I’d Like to modify this class.

Best Regards.

minanoun said...

Hello,

I'd like to share my editing domain, the problem that I can’t find XXXDocumentProvider,where I can find it? I’d Like to modify this class.

Best regards,