Home » Modeling » GMF (Graphical Modeling Framework) » Sharing the same domain between different diagrams
Sharing the same domain between different diagrams [message #1718164] |
Sun, 20 December 2015 19:48  |
Eclipse User |
|
|
|
Good Regards,
I am new to Eclipse GMF and I have many doubts related to domain sharing. I'm actually developing a methodology and diagrams for every diagram is a project part (with its own ecore). I wonder if you can even share the entities being separate projects? I ask because it has entities that are repeated in various diagrams and would make inheritance among diagrams to the user of the methodology is not necessary to redo their work.
Which I have seen some tutorials on the internet that teach to share fields between EMF and GMF, but my goal is different (I think).
Sorry for my bad English.
Thanks and await answers.
|
|
|
Re: Sharing the same domain between different diagrams [message #1718245 is a reply to message #1718164] |
Mon, 21 December 2015 10:10   |
Eclipse User |
|
|
|
Rafhael,
What you describe is the default behavior of EMF models. If you have a model element in one resource (file) that has an EMF reference to a model element in another resource, the file containing the element reference will end up with a URL referencing the other element in the other file. This is all managed by the infrastructure that stores and loads resources.
There are, however, two considerations about which you need to be aware, one regarding the URL and the other regarding the nature of the element reference.
With respect to the URL, it is important that you use the URI.createPlatoformResourceURI() method to create the URI for each resource. Doing so will result in relative pathnames, giving your model files some portability. If you use a "file:\\" prefix for your URL, the file locations will be absolute. Your code should look something like:
URI changeResourceURI = URI.createPlatformResourceURI("/CRL/Change.crl",true);
Resource changeResource = resourceSet.getResource(changeResourceURI,true);
changeResource.load(options);
A second consideration is the manner in which individual elements are identified within a resource. By default, the reference uses a count of the number of that type of object. In other words, if you have a model class Foo and you have three instances of Foo, your reference will be to the the 1st, 2nd, or 3rd instance of Foo. It's not an issue if all of the resources are loaded all the time, but if your referenced resource gets edited independently, the sequence number may no longer reference the instance you intended.
To avoid this problem, designate one of the element attributes as being an identifier in your EMF model and provide a unique ID. I use guids for mine. That way the identity of the referenced object does not change. Of course, you are now obligated to provide that unique identity.
One more thing to be aware of: the folder structure is baked into the URI, and thus into the references. If you have a reference to an element and you move the file to a sub-folder, the references are now broken. It's not a big deal to edit the file containing the reference to change the pathname, but it's a pain. I have not yet found an automated way of moving the files and fixing up the references.
Good luck!
|
|
| | | | | | | |
Re: Sharing the same domain between different diagrams [message #1719439 is a reply to message #1719023] |
Thu, 07 January 2016 16:41  |
Eclipse User |
|
|
|
Rafhael,
I had occasion today to look at my model files as raw text. What I noticed is that the references to other classes in the annotations seem to have the same syntax as the instance references. Therefore your eSuperTypes="Mybase.ecore#//NodeQuadrado" reference should be correct assuming that MyBase.ecore is in the same directory as the file containing the reference. If not, you need to modify "MyBase.ecore" to include a relative path.
|
|
|
Goto Forum:
Current Time: Tue May 20 07:02:45 EDT 2025
Powered by FUDForum. Page generated in 0.04294 seconds
|