How to restore the zoom factor and clipping in the canvas view after model reset?

[rsoika]

When I add a new Element to my model (server side model) I usually reset the GModelState (as recommended) to redraw the complete model.

But then I lose the current zoom factor and clipping on the canvas. The canvas is instead totally reset.

Is it possible to avoid this effect?

[tortmayr]

Hi @rsoika,
yes it is possible to avoid this effect. In fact it's even implemented as the default behavior. For instance if you look at the workflow example you can see that the zoom & current panning state of the canvas persist across model updates:

All actions that manipulate the viewport are dispatched via the FeedbackActionDispatcher which means they get reapplied after a model update. Unfortunatley I don't know why this is not working in your project.

I quickly played around with your editor and noticed that for some operations/updates the zoom factor does not reset
For instance

• Resize a node
• Move a node
• Move a routing point

Creating nodes or editing the labels on the other hand causes a reset.. 😕

[rsoika]

Hi @tortmayr
thanks for your feedback. Yes, I remember that in the early beginnings I disabled some functions form the worklfow example to get a cleaner code base. I will look again into the worklflow example what I missed in my current implementation...

But did I understand you correctly - You mean that I should react on FeedbackActions on the server side and provide the last zoom/clipping information when I reset the GModelState?

The different behavior in my implementation has the background that I do not perform a ModelState reset when resizing a Element Node - in this case I simply update my server model and do not change the GModelState.

[tortmayr]

But did I understand you correctly - You mean that I should react on FeedbackActions on the server side and provide the last zoom/clipping information when I reset the GModelState?

No you don't have to react to these actions. They are handled by the framework and automatically reapplied onto the updated model on client side.
However, this approach can only work if you have stable/deterministic ids.
I guess the problem is the way that you "reset" your GModelState. You have to ensure that

• The id of the graphical model root (GModelState.getRoot()) is the same across model updates
• The revision of the model root is not reset on update

The way we typically do this is that we don't regenerate the entire GModelRoot/Graph on a "model state" reset. Instead we just clear and regenerate the root's children.

Reasoning:

• If the revision property is reset (=-1") the server will send a SetModelAction instead of an UpdateModelAction
• If the id of the root changes between updates, the actions that are reapplied on the client will have an outdated reference to a no longer existing id

[rsoika]

Ah OK, now I understand..