| [EMF] Dedicated editing domain for each model element editor in RCP? [message #1769386] |
Mon, 31 July 2017 09:20  |
 Roman Zimmer
Messages: 27
Registered: November 2010 |
Junior Member |
|
|
Hey @ll,
We are developing a "classic" RCP e4 application for editing different model objects in different editor tabs.
Initial, we had one global editing domain with an assigned command stack shared by all editor tabs. This worked with some flaws. The main problem is that we want to undo only the commands issued in one editor, when the user decides not to save the changes he made in the particular editor. Detecting the dirty state of the editor correctly is also hard as we not always we able to decide if a change on the command stack originated in the tab the user expected it.
To solve the problems, our main idea was to assign a dedicated editing domain to each model element per editor tab and remove it, when closing the editor. If the user decided to save his changes, all commands would have been added to the global command stack or would have been undone when closing the tab without saving. This works good when there is only one editor open at a time.
The editing domain is assigned like this:
modelElement.eResource().eAdapters().add(new AdapterFactoryEditingDomain.EditingDomainProvider(editingDomain));
We are using EMFForms for the UI, which uses AdapterFactoryEditingDomain.getEditingDomainFor(modelElement); internally to retrieve the assigned editing domain.
Debugging the code we saw that with each opened editor a new IEditingDomainProvider is added to the ressource's adapter list leading to retrieve unexpected editing domains using AdapterFactoryEditingDomain.getEditingDomainFor(modelElement);.
We can't seem to get our head around how this is intended to work correctly. Is this the right approach for an e4 RCP application with multiple editing tabs or is there another recommended one? How can we be sure the editing domain assigned to a model element is the one we assigned to it and no other one to correctly undo all commands when not saving? Did we miss something important?
Any hint or help is highly appreciated! If you need some more information, I'm glad to provide it!
Thanks in advance,
Roman
|
|
|
|
| Re: [EMF] Dedicated editing domain for each model element editor in RCP? [message #1769398 is a reply to message #1769396] |
Mon, 31 July 2017 10:36  |
Roman Zimmer
Messages: 27
Registered: November 2010 |
Junior Member |
|
|
Thanks for your input, Ed!
The shared EditingDomain scenario is an obvious choice and quite easy to implement, it works more or less out-of-the-box. From the end user's perspective, we think a distinct EditingDomain scenario feels like a better fit for our application. It avoids the flaws mentioned above and behaves similar to the Eclipse IDE, were changes, saving and redo/undo is managed per tab and not globally.
When editing an object in a tab, we don't want all other tabs to become dirty, too. And closing one tab without saving, we want the object to be like it was before opening, thus undoing the "right" commands is essential. This seems to to lead to the distinct EditingDomains scenario approach. But how to assign an editing domain to an model element such that AdapterFactoryEditingDomain.getEditingDomainFor(modelElement); returns the correct one? It seems that all editing domains are shared to all model elements through it's eRessource()...
|
|
|
|
|
|
|
|
|
|
| Re: [EMF] Dedicated editing domain for each model element editor in RCP? [message #1855464 is a reply to message #1855454] |
Sun, 16 October 2022 06:41 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
For every class Abc there is a generated AbcItemProvider with a getText method. You can specialize it to return what you want for the text: /**
* This returns the label text for the adapted class.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated NOT
*/
@Override
public String getText(Object object)
{
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.03402 seconds
] 
Search
Help
Register
Login
Home
