first steps to start with custom model

[julen9]

Hi, I want to start customizing the java-emf-theia example, but i can not find how to load my own .ecore model. Please, could you tell me where can I find some documentation or first steps? My first goal is only try to add one more node element to the palette. Thanks a lot in advance!

[martin-fleck-at]

Hi @julen9,

I assume you have seen the README and the 'Next Steps' they are proposing with the referenced documentation.

In the example repository, we use the TaskListSourceModelStorage to properly set up our resource set that is used when loading a model from a URI provided by the RequestModelAction from the client. The crucial part here is that the resource set that we use to load the model knows about our custom Ecore-based package so we need to register our package accordingly.

If you want to add one more node element - that does not yet exist in the model.ecore - to the palette, your first step would be to add it to the ecore (or replace it with your own file if you already have one) and then re-generate the model code using the model.genmodel file. This will create the new sources in the src-gen folder from where you can reference them when we translate the semantic model to the GModel. Please make sure that your custom type is somehow part of the "root" element (in the example that is the TaskList).

Afterwards, you need to make sure that your semantic element is properly translated to something that GLSP understands, i.e., the Graphical Model Structure. One very important aspect is the type which is used to map elements to their graphical representation.

1. Specify a custom type for your element to make changes and adaptations easier. Some types are already defined in TaskListModelTypes.
2. Adapt the TaskListToolPaletteItemProvider to add an entry to the tool palette for your custom node. Here you can do something similar to createTask but make sure to use your own type id. That is already sufficient to get the entry into the tool palette. However, GLSP still does not know how to create, map, or render the custom element.
3. Create a custom AbstractEMFCreateNodeOperationHandler or your type (the constructor takes the element type id) and register it in the TaskListDiagramModule. This command should create the semantic element in the semantic Ecore-based model and the shape in the notation model.
4. Adapt the TaskListGModelFactory to ensure that any instances of your class that you find in a TaskList root node are properly translated to a GModel representation, e.g., a GNode that has your type.
5. Ensure that on the client side your custom type is properly mapped to a visual representation, e.g., a node with rounded corners.

I've also quickly sketched this on an example branch here: eclipse-glsp/glsp-examples@master...example-javaemftheia-extension

Hope that gets you started in the right direction.

[DaveHOnCode]

Hi @martin-fleck-at,

What do you mean by

Please make sure that your custom type is somehow part of the "root" element (in the example that is the TaskList)

We are planning to mirgrate from a self programmed webapplication to the java / theia / emf combination. We already replaced the source model with our own custom model, but the resolved semantic element of the notation model does not get filled so far.

Thank you so much!

[martin-fleck-at]

What I meant by that was simply that you usually only have one root entry point in Ecore and in your diagram and you should make sure that the other elements are reachable from there by being part of the root tree. In the TaskList example both Task and Transition elements are part of the TaskList root element. When we fill the GModel root element with the Ecore root element (binding, implementation) we have a 1:1 mapping between Task -> Node and Transition -> Edge.

but the resolved semantic element of the notation model does not get filled so far.

I do not fully understand what you mean by that.

[DaveHOnCode]

Thank you for your answer @martin-fleck-at !

We replaced parts of the code in the TaskListGModelFactory.fillRootElement(final EObject semanticModel, final Diagram notationModel, final GModelRoot newRoot) method with our own code.

The notationModel which is passed into this function does contain a semanticElement.resolvedSemanticElement which is null.

The semanticModel does contain the whole meta model (as expected) althought.

Is there anything else what we have to take care about?

Thanks in advance!

[martin-fleck-at]

That is interesting, we set the semantic element on the notation element during indexing in the EMFNotationModelIndex. This index implementation is automatically used when your diagram module inherits from EMFNotationDiagramModule and you do not re-bind the index yourself.

Does your GModelFactory inherit from EMFNotationGModelFactory? Do you override the fillRootElement(GmodelRoot) call or the fillRootElement(EObject, Diagram, GModelRoot) call? The first one has this line modelState.getIndex().indexAll(notationModel, semanticModel); that should trigger the correct indexing. Maybe you can debug into that to see why the semantic elements may not be set?

[DaveHOnCode]

okay I found the problem. Our model did not implemented the Identifiable type.

Now it seems to work - thank you for the indexing hint, that helped to find the problem

[esdrascubas]

Thanks, @martin-fleck-at ,

Very userful answer. I created a new model (ecore and genmodel) and I generated all the classes and implemented a brand new classes to create a new glsp-server with my model. Now, I'm working on the client side. I will be back with new questions.

Thanks a lot!