Cross-referencing over models

[jgsuess]

I am trying to create cross-resource cross-references in the graphical or tree editor. Is this possible? How does it work?

[planger]

Hi,

Sure, this is certainly possible. Both editors (graphical and tree editor) are eventually talking to a backend that loads EMF models. In EMF, every object is referenced via URI. For file-internal references, the URI is typically only a fragment pointing to an object (e.g. #id). For cross-file references, the URI points to another file plus the fragment to identify the object within this other file.

When you load a resource in EMF, initially all cross-file references are not resolved, but proxies are installed where the referenced object would go. The proxy contains the URI that is needed to eventually resolve the reference. Once you access it or do a resolveAll (see EcoreUtils), the referenced resource is loaded into the resource set and all proxies pointing to that resource are replaced with the actual objects.

For the clients, such as GLSP or tree editor, all of that doesn't really matter, because they just request a URI and get the model. The EMF Model Server deals with loading the files into the resource set and potentially resolving cross file references and returns the resulting model in the respective format (JSON or XMI).

[jgsuess]

Thank you for the helpful response. I am aware that the backend is capable of loading arbitrary EMF data into a workspace. What I wanted to know was if the system is able to create those cross references in The user interface. So what I am trying to say is: is there a capability much like the one in the reflective Ecore editor in the current user-interface that allows to set and commit cross-references?
And if that exists, how would such a functionality be implemented when interacting with a diagramming system. Can a GLSP view visualise a compound model made up of several resources? How easy is it to implement such a mechanism?

[CamilleLetavernier]

Hi,

In general, the GLSP Client does not need to know about cross-references at all, as it typically receives a synthetic view of the model (merged into a single Json object). The model is usually merged by the GLSP Server, which can request multiple models/resources from EMF. The GLSP Server will also be responsible for managing and editing these EMF resources (either directly, or through Commands/Patches sent to the Model server).

To trigger cross-resource changes, the GLSP Client will send some high level actions (Such as a CreateOperation, or maybe a specific custom operation based on your actual use case), and the GLSP Server will be responsible for identifying which resources need to be loaded/edited to realize this Operation (Again, either directly - by loading and editing resources itself, or indirectly - by forwarding high-level or low-level Commands to the Model Server).

The rule of thumb is: if GLSP is your only editor, then the GLSP Server can handle these high-level operations directly. If you have multiple editors/views working on your model, delegating to the Model Server usually makes sense, to avoid redundancy (In that case, the GLSP Server handles diagram-related changes, and delegates all semantic-model changes to the Model Server).

Since the GLSP Client doesn't know about multi-resources, this is quite straightforward: all the logic is hidden in the GLSP Server, in a GModelFactory (that generates the merged Diagram Json Object from your arbitrary backend data, e.g. EMF Resources, and sends it to the client).