General questions about the EMFNotationSourceModelStorage

[MichaZoomZoom]

Hi everyone,
I got some questions about the EMFNotationSourceModelStorage:

1. Are there any preconditions to the metamodel to use this storage? I saw there is a mapping between the elements of the semantic and notation model, done by the EMFSemanticIdConverter. The 'TaskList' nodes provide an 'Identifiable' which is set during the task creation in the handler. So the subquesition would be is this the id the converter uses or exists there any other id in the background? I want to reuse an existing metamodel which does not provide such an 'Identifiable' - the elements are just distinguished by there names, so maybe I could adapt this.

2. How do I start a client session without any existing source model files in the app folder of the client? Do I have to provide any empty notation or semantic model files or could I even reuse a semantic model from a Sirius-Editor with the same metamodel? Or do I have to implement something which creates them?

I would be thankful for any kind of help. And please tell me if there are already wrong assumption in the questions, I am just new to the whole topic.

[ndoschek]

Hi @MichaZoomZoom,
Thank you for your interest in GLSP 🎉 🙌

Part 1:
Overall, the notation model requires some identifier (i.e., elementId) to be able to be linked to the semantic element.
You can find the notation Ecore model here: GLSP Notation Ecore Model.

If your elements are uniquely identified by their names, you can use these names as elementIds. This approach should work as long as you ensure the uniqueness of the element names.

For further reference, you might find this example useful: GLSP Examples - Java EMF Eclipse.

Additionally, you could store notation-related properties directly in the semantic model.
In many of our examples, we've moved away from a strict separation between semantic and notation models because it's generally easier to maintain when combined.
However, keeping notation information in a separate model has its own advantages, like separation of concerns.

Part 2:
We typically create a custom command or handler to generate the empty model files.
Typically this is triggered by a Theia command, also using the QuickInput feature to allow the user to define the model name for example.

From an older example of ours, I can share a snippet, where we created the empty models on the backend to ensure the user can create an project (consisting of an empty semantic and notation model).

...
   protected Model createNewModel(final URI modelUri) {
      Model newModel = MyModelFactory.eINSTANCE.createModel();
      String modelName = modelUri.lastSegment().split("." + modelUri.fileExtension())[0];
      newModel.setName(modelName);
      return newModel;
   }

   protected Diagram createNewDiagram(final Model model) {
      Diagram newDiagram = NotationFactory.eINSTANCE.createDiagram();
      SemanticElementReference semanticElement = NotationFactory.eINSTANCE.createSemanticElementReference();
      semanticElement.setUri(EcoreUtil.getURI(model).fragment());
      newDiagram.setSemanticElement(semanticElement);
      return newDiagram;
   }
...

I hope this helps! If you have any more questions or need further assistance, please don't hesitate to reach out. ✨
Best,
Nina