Closed tortmayr closed 5 years ago
In future changes this API shall be extended to support ModelStates for both the graphical and the semantic model
I think this is an interesting point for discussion, ie whether we actually want to make GLSP aware of a model state at all rather than just letting it manage a graphical model state. I think it has some advantages of keeping it agnostic of how the graphical model actually has been constructed (from a semantic model + notation or anything else?) and put an own component before GLSP that actually constructs the model and translates changes GLSP applied to the graphical model to the respective semantic model and notation model etc. What do you think?
According to my experiments so far, there is indeed no need for GLSP to be aware of the separation between semantics and notation (Although each specific GLSP Server Implementation should be able to translate from/to a Semantic + Notation <-> GSLP model graph)
This is also the case for desktop diagram applications: the UI part (e.g. GEF) only cares about presentation & interactions, and doesn't need to know anything about the separation between Notation and Semantics (Specific to GMF)
Cleanup and major refactorings of the GLSP server API. Also incorporates some of the relevant latest changes from https://github.com/eclipse/sprotty-server.
Summary: