Implementing domain specific language

[jobdk]

My goal is to develop a GLSP-Server with my own domain specific language. To implement this, a data model already exists as ecore.

The plan is to exchange the existing ecore model and the generated code in the workflow project. With the current data model in the workflow example, there is no extra mapping needed, as I see it. As my data model is not that easy to map to the glsp-graph I need to map my data model to the glsp-graph.

My question is, if that would be the correct way to proceed, as I could not find any documentation about it.
Could you give me a hint where the mapping takes place or if there are any examples available?

Thank you very much!

[planger]

You are on the right path!

In the simple workflow example, the GModel is loaded from a JSON file and manipulated directly. Thus, there is no mapping required from the original model source (in this case the GModel itself) and the GModel that is then sent to the client. This is just to keep the example as simple as possible.

In most of the actual GLSP-based diagram editor implementations that I'm aware of, the model source is not the GModel directly, but rather another resource, such as an EMF model or something else. In those cases, you need to do the following:

1. Typically you want to extend the GModelState class to be able to store your custom model source in a typed way and keep a mapping to the GModel later on. Therefore, you can register your custom GModelState class via bindGModelState() in the diagram module.
2. Register your custom ModelSourceLoader via bindSourceModelLoader(), which knows how to load your original model source (e.g. an EMF Model) into your model state.
3. Register your custom GModelFactory class via bindGModelFactory() which implements the transformation of your custom model into the GModel.

All operation implementations should then manipulate the original model source (EMF model). This would then re-trigger the invocation of your registered model factory to produce a new version of the GModel after every original model source update.

[jobdk]

Thank you for your answer.

I registered my custom classes.

@Override
    protected Class<? extends GModelState> bindGModelState() {
        return  ModelerModelState.class;
    }
@Override
    protected Class<? extends ModelSourceLoader> bindSourceModelLoader() {
        return ModelerModelSourceLoader.class;
    }
@Override
    protected Class<? extends GModelFactory> bindGModelFactory() {
        return ModelerModelFactory.class;
    }

Unfortunately I still struggle to implement these classes, are there any example implementations or is there documentation where a different model source is used than the GModel?

Am I right that the following happens on start:

1. User opens the diagram
2. client sends RequestModelAction with the diagramType and URI of the source model to the server (in this case URI to the model build with the custom EMF)
3. server loads the model source in the model state
4. custom model factory maps source model to the GModel
5. GModel is sent back to the client and rendered accordingly.

Thank you very very much!

[planger]

Yes, your sketch of what happens during the start-up is exactly right.
There are a few open-source diagram implementations available that are working with an EMF-based / external model. They however also use a model server component to load and manage the model state, which you may not need. But still those diagram implementations should still be helpful:

• Ecore GLSP: see Diagram Module
• UML GLSP: see Diagram Module

Documentation is currently work in progress and an initial version of the docs will be available soon. In the meantime you can have a look at the preview of the documentation.

[jobdk]

This is helping me a great deal. Thank you very much!