Drag and drop and RequestPopupModelAction

[csamarchi]

Hello,

I'm working with Node server and VS Code extension. I got part of my source model to render in the client, however, everything is stacked on top of each other in the left corner. I am able to click and drag, except when I let go of the click to drop, the module resumes back to its original spot stacked on top of the others.

I see this error in the server:

What is the purpose of the saveSourceModel() function in the storage.ts file? Does this have anything to do with dragging and dropping and saving the position of where it's dropped?

I'm surprised my modules are not laid out in the same format as the out of the box example, any ideas as to why? Is this something within the server or the client?

Maybe because edges are not defined properly? Here is my gmodel-factory:

 export class ModuleGModelFactory implements GModelFactory {
     @inject(ModuleModelState)
     protected modelState: ModuleModelState;

     createNodes(): void {
         // def? this.modelState.source.def
         const moduleArray: Module[] = this.modelState.source.def.modules.map((module: Module) => {
             const inputsArray = module.inputs.map((input: Input) => {
                 const tempBuild: Input = Input.builder().name(input.name).value(input.value).build();
                 return tempBuild;
             });
             const outputsArray = module.outputs.map((output: Output) => {
                 const tempBuild: Output = Output.builder().name(output.name).metaType(output.metaType).build();
                 return tempBuild;
             });
             const source = Source.builder().sourceType(module.source.sourceType).build();
             // eslint-disable-next-line max-len
             const solutionModule = Module.builder().name(module.name).source(source).inputs(inputsArray).outputs(outputsArray).build();
             return solutionModule;
         });
         this.modelState.modules = moduleArray;
     }

     createModel(): void {
         this.createNodes();
         const modules = this.modelState.modules;
         this.modelState.index.indexModule(modules);
         const moduleNodes = modules.map(module => this.createModule(module));
         const newRoot = GGraph.builder().id(module.id).addChildren(moduleNodes).revision(0).build();
         this.modelState.updateRoot(newRoot);
     }

     protected createModule(module: Module): GNode {
         const builder = GNode.builder() //
             .id(module.id)
             .addCssClass('tasklist-node')
             .add(GLabel.builder().text(module.name).id(`${module.id}_label`).build())
             .layout('hbox')
             .addLayoutOption('paddingLeft', 5)
             .position(module.position);

         if (module.size) {
             builder.addLayoutOptions({ prefWidth: module.size.width, prefHeight: module.size.height });
         }

         return builder.build();
     }
 }

[planger]

Hi @csamarchi,

The error you are seeing about the RequestPopupModelAction is unrelated to the positioning issue of your nodes. This seems to be because the RequestPopupModelActionHandler can't find the element for which the popup (hover widget) was requested. This is likely because the index isn't populated correctly for your elements?

Your ChangeBoundsHandler is responsible to process element moves and resizes invoked by the user, e.g. when they drag and drop an node to a new position on the client. As can be seen in the change bounds handler in the project template, it sets the position and size from a ChangeBoundsOperation, sent by the client after e.g. a move, in the source model. This should trigger a model update so that your GModelFactory is invoked again and hence it will create a new GModel with the new positions, as it reads the positions from the respective properties of the source model.

Unfortunately, I can't tell what's exactly wrong. It looks like you are reading positions from your source model and apply them to the GModel nodes in your GModelFactory here:

.position(module.position);

So I'd debug into that line and see what it actually writes into the position of the GModel nodes.

Your ChangeBoundsHandler in turn should obtain the correct module object from the GModel node ID (usually with the help of the index) and write the new position of the ChangeBoundsOperation back into module.position of the modelState. This way, it should get updated in the source model of the modelState, and thus considered on re-generation of the GModel on the next GModel update.

Since your module nodes seem to pop back to their original positions after a drag and drop, it looks like there is something missing in the process of reading the positions from the source model, writing them into the GModel and updating the source model after a ChangeBoundsOperation. So I'd step through the code in debug mode along those lines.

The purpose of saveSourceModel() is to store back the current version of your source model -- after potential modifications -- from your modelState into the persistent storage, such as a file, from where your source model originally has been loaded. It is usually invoked when the user saves the diagram (e.g. Ctrl-s) on a dirty diagram editor. See also https://www.eclipse.org/glsp/documentation/sourcemodel.

[planger]

Yes, that's the line where the root element ID is set in the GModelFactory.

Once we make a change, the client sends an action.

Yes, it will send an operation, depending on the change. E.g. a ChangeBoundsOperation if the user moved or resized an element.
The client itself doesn't really make a change though. It just sends the aforementioned operation to request the server to perform the change, which then typically sends back an UpdateModel with the new GModel after the change is applied.

Does the client also send a new ID back to the server?

No. The server is the only one who maintains and assigns IDs in the GModelFactory. The client just uses those IDs to refer to elements as a context of operations or actions.

[csamarchi]

Ok, does the server assign new id's to the same element on changes? Because I am seeing new id's after changes

[csamarchi]

const hoverElement = this.modelState.index.find(action.elementId);

doesn't find an element in your index for the action.elementId, which is I think the GModel root element ID. So it seems you didn't put an entry for your GModel root element ID to the GModel root element into the map.

Could you elaborate on this? It's looking for the element ID in the index. What do you mean by entry for my GModel root element ID into the map?

[csamarchi]

Where in your example is taskList's id initially being set?
This line:
const newRoot= GGraph.builder().id(taskList.id).addChildren(childNodes).build();

I understand is setting the initial element root ID, but it's pulling taskList.id and I'm curious where this comes from. Is it the builder() function when we create the modules?

[planger]

Ok, does the server assign new id's to the same element on changes? Because I am seeing new id's after changes

This depends on your implementation of the GModelFactory. That is, this is up to you. I would recommend to keep the GModel IDs stable to avoid flickering on updating the model. The framework itself doesn't generate new IDs. Your specific GModelFactory implementation is the only place where IDs should be generated and assigned to GModel elements (and then update the index).

Could you elaborate on this? It's looking for the element ID in the index. What do you mean by entry for my GModel root element ID into the map?

The default implementation GModelIndex keeps a map of ids to GModel elements. It looks like it can't find action.elementId in this map. When you call modelState.updateRoot(yourGmodelRoot), the default implementation should invoke modelState.index.indexRoot(yourRoot) to populate the index on each model update. Is this called in your scenario?
You can debug into that code and see what it actually indexes and which IDs are there and compare this to the ID that the RequestPopupModelActionHandler is trying to find in the index.

I understand is setting the initial element root ID, but it's pulling taskList.id and I'm curious where this comes from. Is it the builder() function when we create the modules?

taskList is the source model of this example, so it is a custom domain-specific model that is represented by the diagram of your diagram editor. Thus taskList.id is just an id of this source model. Of course, task list is just a random example model. In your case this will likely be something different, depending on the domain of your diagram. Whether your domain model has a stable ID or not, or whether you somehow generate an ID, is up to you.
I however would recommend adding an ID to your source model and use it in your GModelFactory for the IDs of GModel elements that represent your source model element. This makes things more clear and simpler.

I hope this helps!

PS: Sorry, I needed to update this answer a bit, as I realized it isn't very clear in certain places.

[csamarchi]

Thank you, could you explain what the purpose of the index file is?

[planger]

It is used to export certain modules. E.g. if in package my-package there is a src/abc/def/index.ts that exports a file mymodule.ts which exports e.g. a class MyClass, other packages can add a dependency to my-package and import the exported classes, functions, etc. from this package by importing from import { MyClass} from 'my-package/lib/abc/def'. Otherwise it would have to be imported from the file directly 'my-package/lib/abc/def/mymodule'. Thus if the filename changes or MyClass would be moved, everyone would have to update their imports. With an index.ts the maintainers can just change it there and all imports can stay the same.

Note that this description simplifies it a lot as there are configurations in play like out folders (lib), etc. But this is roughly how it would work in the configuration of GLSP.

[csamarchi]

Thanks for the explanation.

I noticed in the example.wf file the initial positions radius's are given for each child like so:

      "children": [
        {
          "cssClasses": [],
          "type": "comp:header",
          "id": "task0_header",
          "position": {
            "x": 5,
            "y": 5
          },
          "size": {
            "width": 88.5859375,
            "height": 42
          },

Which is where the initial positioning is coming. Since we are not using the example file, we are using our own, how are we suppose to apply each position to each child? I don't expect us to hard code the initial x,y coordinates for each node, but I don't know how else?

[planger]

As you are using your own source models, the positions for each node need to come from your source models too. You have to store the positions in your source model or derive it from other properties of your source model or compute them with auto-layouting (e.g. with ELK) and eventually apply them to the GModel nodes you create in the GModelFactory.

GLSP doesn't put any restrictions or makes any assumptions on where you store the positions or how you compute them. Eventually however they need to end up in the GModel. It is really up to you where to get those positions from. Often they are just stored in the source model(s) alongside each object that end up as a node in the diagram.
If you don't want to "pollute" your original source model with this layout data though (e.g. if this format is not under your control), a common approach is also to have a second source model that just stores the positions (like this is x and y for that node in this other model).