| EditingDomains [message #526600] |
Mon, 12 April 2010 11:56  |
Eclipse User |
|
|
|
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 #531865 is a reply to message #527436] |
Thu, 06 May 2010 12:23  |
| Eclipse User |
|
|
|
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 #601961 is a reply to message #527436] |
Thu, 06 May 2010 12:23 |
| Eclipse User |
|
|
|
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.
|
|
|
Powered by
FUDForum. Page generated in 0.02957 seconds
] 
Search
Help
Register
Login
Home
