Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Papyrus » EditingDomains
EditingDomains [message #526600] Mon, 12 April 2010 11:56 Go to next message
Eclipse UserFriend
Originally posted by: luzi.anderegg.ergon.ch

Hi,

i'm working on a project where multiple graphical and non-graphical
editors exist for one semantical model. hence, the setting reminds me of
the multi-editor views papyrus. currently, we are struggling with
editing domains.
how does Papyrus handle editing domains? is there one global editing
domain for all editors or is there an editing domain per editor
(although in our setting, the different views do not have to be in the
same editor)?

thanks for any hints,
luzi
Re: EditingDomains [message #527436 is a reply to message #526600] Thu, 15 April 2010 09:19 Go to previous messageGo to next message
Vincent   is currently offline Vincent Friend
Messages: 35
Registered: December 2009
Member
With MDT Papyrus, I suggest using the method :
org.eclipse.papyrus.core.utils.EditorUtils.getTransactionalE ditingDomain()
to get the editing domain. If you do not use Papyrus, you can have a look at its implementation and be inspired by it.

This EMF Editing domain is shared between all diagrams of the multi-diagram editor.

You can use it to work on either the EMF model, or the views (which are also EMF elements) used for graphical aspects.


This TransactionalEditingDomain is constraining in the fact it forces the usage of transactionnal commands. But this approach is the best way to proceed. Only transactional commands will support easily undo/redo features and live validation provided by emf and called by gmf (constraints declared with the org.eclipse.emf.validation.constraintProviders and org.eclipse.emf.validation.constraintBindings extension points).

The most important point is to always use the same method to recover the editing domain (preferably the editor's one), so that you do not have to handle multiple command stacks.

If you use several (non transactional) editing domain, this will lead to modifications which impact other views and can not be undone in these views. This may even lead, after an undo, to impacts visible in the editor, whithout the editor being dirty.
Re: EditingDomains [message #531865 is a reply to message #527436] Thu, 06 May 2010 12:23 Go to previous message
Eclipse UserFriend
Originally posted by: luzi.anderegg.ergon.ch

see further questions inlined
Vincent H schrieb:
> With MDT Papyrus, I suggest using the method :
> org.eclipse.papyrus.core.utils.EditorUtils.getTransactionalE ditingDomain()
> to get the editing domain. If you do not use Papyrus, you can have a
> look at its implementation and be inspired by it.
>
> This EMF Editing domain is shared between all diagrams of the
> multi-diagram editor.
ok. as far as i know implies sharing one transactional editing domain
that there is only one resource set. does this have any consequences
(e.g on performance)? do you know anything about the implications for
the modification tracker gmf adds to the resource?

thanks again
>
> You can use it to work on either the EMF model, or the views (which are
> also EMF elements) used for graphical aspects.
>
>
> This TransactionalEditingDomain is constraining in the fact it forces
> the usage of transactionnal commands. But this approach is the best way
> to proceed. Only transactional commands will support easily undo/redo
> features and live validation provided by emf and called by gmf
> (constraints declared with the
> org.eclipse.emf.validation.constraintProviders and
> org.eclipse.emf.validation.constraintBindings extension points).
>
> The most important point is to always use the same method to recover the
> editing domain (preferably the editor's one), so that you do not have to
> handle multiple command stacks.
>
> If you use several (non transactional) editing domain, this will lead to
> modifications which impact other views and can not be undone in these
> views. This may even lead, after an undo, to impacts visible in the
> editor, whithout the editor being dirty.
Re: EditingDomains [message #601936 is a reply to message #526600] Thu, 15 April 2010 09:19 Go to previous message
Vincent   is currently offline Vincent Friend
Messages: 35
Registered: December 2009
Member
With MDT Papyrus, I suggest using the method :
org.eclipse.papyrus.core.utils.EditorUtils.getTransactionalE ditingDomain()
to get the editing domain. If you do not use Papyrus, you can have a look at its implementation and be inspired by it.

This EMF Editing domain is shared between all diagrams of the multi-diagram editor.

You can use it to work on either the EMF model, or the views (which are also EMF elements) used for graphical aspects.


This TransactionalEditingDomain is constraining in the fact it forces the usage of transactionnal commands. But this approach is the best way to proceed. Only transactional commands will support easily undo/redo features and live validation provided by emf and called by gmf (constraints declared with the org.eclipse.emf.validation.constraintProviders and org.eclipse.emf.validation.constraintBindings extension points).

The most important point is to always use the same method to recover the editing domain (preferably the editor's one), so that you do not have to handle multiple command stacks.

If you use several (non transactional) editing domain, this will lead to modifications which impact other views and can not be undone in these views. This may even lead, after an undo, to impacts visible in the editor, whithout the editor being dirty.
Re: EditingDomains [message #601961 is a reply to message #527436] Thu, 06 May 2010 12:23 Go to previous message
Eclipse UserFriend
Originally posted by: luzi.anderegg.ergon.ch

see further questions inlined
Vincent H schrieb:
> With MDT Papyrus, I suggest using the method :
> org.eclipse.papyrus.core.utils.EditorUtils.getTransactionalE ditingDomain()
> to get the editing domain. If you do not use Papyrus, you can have a
> look at its implementation and be inspired by it.
>
> This EMF Editing domain is shared between all diagrams of the
> multi-diagram editor.
ok. as far as i know implies sharing one transactional editing domain
that there is only one resource set. does this have any consequences
(e.g on performance)? do you know anything about the implications for
the modification tracker gmf adds to the resource?

thanks again
>
> You can use it to work on either the EMF model, or the views (which are
> also EMF elements) used for graphical aspects.
>
>
> This TransactionalEditingDomain is constraining in the fact it forces
> the usage of transactionnal commands. But this approach is the best way
> to proceed. Only transactional commands will support easily undo/redo
> features and live validation provided by emf and called by gmf
> (constraints declared with the
> org.eclipse.emf.validation.constraintProviders and
> org.eclipse.emf.validation.constraintBindings extension points).
>
> The most important point is to always use the same method to recover the
> editing domain (preferably the editor's one), so that you do not have to
> handle multiple command stacks.
>
> If you use several (non transactional) editing domain, this will lead to
> modifications which impact other views and can not be undone in these
> views. This may even lead, after an undo, to impacts visible in the
> editor, whithout the editor being dirty.
Previous Topic:Getting org.eclipse.ocl.SemanticException: Cannot find operation (allOwnedElements()) for the type..
Next Topic:Changin Element properties by applying stereotypes?
Goto Forum:
  


Current Time: Wed Aug 12 21:24:13 GMT 2020

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

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

Back to the top