Home » Modeling » Sphinx » Same Editing domain for different model descriptor(Sphinx shared editing domian for different model descriptor)
|
Re: Same Editing domain for different model descriptor [message #1698751 is a reply to message #1698577] |
Wed, 17 June 2015 15:17 |
|
Hi,
It is very strange that you end up with different editing domains for your 3 Ecore models. Normally, when you have set up a correctly configured metamodel descriptor, Sphinx ALWAYS loads ALL files that contain instances of the metamodel in question into the SAME workspace-wide shared transactional editing domain.
In order to be able to help you, I need to know more details about what you have done and intend to do:
> Background :
> We have three different Ecore model A, B, C
> where C holds reference to A and B
> where B holds reference to A
Do you mean literally EMF Ecore models or your own model files that are based on a custom metamodel defined with Ecore?
Do you have 3 models in the sense of the Sphinx IModelDescriptors or just 3 different model files?
> Each model have there own editors and serialized to individual files.
What kind or editors?
Are they Sphinx-based or do you mean the traditional model editors generated by EMF?
> Issue facing or not clear:
> We are using Sphinx framework, where we have defined there own
> model-descriptors for A,B and C
Do you mean IMetaModelDescriptors? The IModelDescriptors are automatically created by Sphinx and don't need to be provided by adapters.
> On trying to retrieve the editingdoamin,
> i.e TransactionalEditingDomain getEditingDomain(IModelDescriptor
> modelDescriptor)
> it returns different for eobjects of A, B and C.
Do you mean org.eclipse.sphinx.emf.util.WorkspaceEditingDomainUtil.getEditingDomain(IModelDescriptor)?
> Is it possible to get one common or shared editingdomain for all the
> model. Any hints would be helpful.
As I said, this is the default behavior of Sphinx. When everything is alright then it is hardly possible to make it happen that Sphinx loads instance files of the same metamodel into different editing domains.
Regards,
Stephan
|
|
|
Re: Same Editing domain for different model descriptor [message #1698996 is a reply to message #1698751] |
Fri, 19 June 2015 11:39 |
byrebg Mising name Messages: 48 Registered: July 2009 |
Member |
|
|
Thanks for the feedback, please find my comments.
Hi,
It is very strange that you end up with different editing domains for your 3 Ecore models. Normally, when you have set up a correctly configured metamodel descriptor, Sphinx ALWAYS loads ALL files that contain instances of the metamodel in question into the SAME workspace-wide shared transactional editing domain.
In order to be able to help you, I need to know more details about what you have done and intend to do:
> Background :
> We have three different Ecore model A, B, C
> where C holds reference to A and B
> where B holds reference to A
Do you mean literally EMF Ecore models or your own model files that are based on a custom metamodel defined with Ecore?
Byre : We have modelled three different custom model using ecore_diagram, to our domain requirement like manager.ecore, dependent.ecore and configure.ecore
depenedent.ecore has reference to manager.ecore i.e Eobject in depenedent referes to Eobject in manager
configure.ecore has reference to both depeendent.ecore and manager.ecore
Do you have 3 models in the sense of the Sphinx IModelDescriptors or just 3 different model files?
Byre : Apologies here, we have 3 different IMetaModelDescriptors not Imodeldescriptors, with unique uri and namespace of ecore model
> Each model have there own editors and serialized to individual files.
What kind or editors?
Byre : Its a form based editors extending the "BasicTransactionalFormEditor" of sphinx
Are they Sphinx-based or do you mean the traditional model editors generated by EMF?
Byre : We have generated only model and edit code not the editor, its custom form editor which is extending the BasicTransactionalFormEditor. We have explorer also which use ExtendedCommonNavigator to show the content of all the 3 models with transient nodes
> Issue facing or not clear:
> We are using Sphinx framework, where we have defined there own
> model-descriptors for A,B and C
Do you mean IMetaModelDescriptors? The IModelDescriptors are automatically created by Sphinx and don't need to be provided by adapters.
Byre : Exactly its Imetamodeldescriptors, which we need to specify else the it would fail saying no metamodeldescriptors found
> On trying to retrieve the editingdoamin,
> i.e TransactionalEditingDomain getEditingDomain(IModelDescriptor
> modelDescriptor)
> it returns different for eobjects of A, B and C.
Byre : To be more precise we have eclipse project, where all the three models resides. Via Navigator when try to open the models which would open in their respective individual form editors.
i,e Manger Editor, Dependent Editor and Configuration Editor
Exact problem : We have certain data of manger editor displayed in configuration editor, now via EMF command if any changes made related to manager model in configuration editor it does not updates the value in manager editor or makes that editor dirty.
On analyzing deeper we found the each editor had its own editing doamin which executed commands on respective editing domain stacks.
Do you mean org.eclipse.sphinx.emf.util.WorkspaceEditingDomainUtil.getEditingDomain(IModelDescriptor)?
Byre : Yes, On digging deeper we saw that it invokes ModelDescriptor(IMetaModelDescriptor mmDescriptor, TransactionalEditingDomain editingDomain, IResourceScope resourceScope) thrice for each model browsed.
> Is it possible to get one common or shared editingdomain for all the
> model. Any hints would be helpful.
As I said, this is the default behavior of Sphinx. When everything is alright then it is hardly possible to make it happen that Sphinx loads instance files of the same metamodel into different editing domains.
Regards
BG
|
|
|
Re: Same Editing domain for different model descriptor [message #1699084 is a reply to message #1698996] |
Sat, 20 June 2015 15:23 |
|
Hi,
Thank you for sharing the requested additional details, this gives a much better picture of what you are intending to do.
Given that you have 3 different metamodels (rather than just 3 different instance model files that are based on the same metamodel) that are represented by 3 different IMetaModelDescriptors it is indeed normal that - by default - Sphinx the instance model files into different TransactionalEditingDomains. This is a consequence of the general shared editing domain mapping policy in Sphinx which creates and manages a separate TransactionalEditingDomain instance for each metamodel (where metamodel is defined by an IMetaModelDescriptor).
But this is, as mentioned, only the default behavior, and there 2 possible ways to go around that:
a) Contribute a ITargetMetaModelDescriptorProvider that returns the IMetaModelDescriptor of manager.ecore as target IMetaModelDesriptor of configure.ecore and dependent.ecore
That way, you can tell Sphinx to handle configure.ecore and dependent.ecore like extensions to manager.ecore and Sphinx then kindly uses the shared TransactionalEditingDomain of manager.ecore to accommodate the model instance files of all 3 metamodels.
The usecase that had initially driven the creation of the ITargetMetaModelDescriptorProvider is GMF. GMF diagram files are models based on the GMF Notation metamodel and would normally be loaded into a dedicated TransactionalEditingDomain instance that Sphinx would allocate for that metamodel. However, GMF diagram files NEVER live on their own but always reference the domain model objects that they represent graphically. These domain model objects are ALWAYS based on a metamodel that is different from GMF Notation. Nevertheless, to make sure that the references from the GMF Notation objects to the domain model objects can be resolved, both must be loaed into the SAME TransactionalEditingDomain/ResourceSet.
To see how an ITargetMetaModelDescriptorProvider can be implemented and how it must be contributed to the org.eclipse.sphinx.emf.metaModelDescriptors extension point have a look at org.eclipse.sphinx.gmf.workspace.metamodel.GMFTargetMetaModelDescriptorProvider and /org.eclipse.sphinx.gmf.workspace/plugin.xml.
b) Replace the three IMetaModelDescriptors by a single common IMetaModelDescriptor for all 3 Ecore models
This is an alternative approach which I've never tried but could work also. The common IMetaModelDescriptor would need to be designed to match the EPackage namespace URIs of all 3 Ecore models. This can be achieved by providing a common base namespace and an appropriate regular expression as ePackageNsURIPostfixPattern to the AbstractMetaModelDescriptor(String, String, String, String) constructor.
Stephan
|
|
| |
Re: Same Editing domain for different model descriptor [message #1700657 is a reply to message #1700182] |
Mon, 06 July 2015 09:30 |
|
Hi,
> Looking deeper, where we contribute to the extension
> "org.eclipse.ui.navigator.navigatorContent", we have three contribution of
> custom content provider and label provider since its required to hide few
> tree nodes and add transient nodes for each different models.
Yes that should be fine.
> Clarification, since its required to specify the trigger points with properties
> to test property: org.eclipse.sphinx.emf.metaModelIdMatches
> value as "manger contenttype" similarly to dependent and configure . So in
> this case what we need to specify ?
It is not necessary to specify advanced kinds of expressions for the extension metamodels. Not knowing enough details of how your metamodels are structured and nested into each other, I cannot tell you which expression would be appropriate. But what you can to is to put an <or/> child element as trigger point which should have the effect that you see the content in any case. If it works but you find that you see "too much" content then you can start from there and add more conditions/property testers as appropriate.
Also take care of specifying the possibleChildren appropriately.
Kind regards,
Stephan
[Updated on: Mon, 06 July 2015 09:30] Report message to a moderator
|
|
|
Goto Forum:
Current Time: Tue Dec 03 11:52:34 GMT 2024
Powered by FUDForum. Page generated in 0.02805 seconds
|