how to handle the glspUndo operation

[rileydanejohnston]

Hello,
Is there a simple example for how to implement the glspUndo operation? I'm getting an error in devTools that there isn't a handler for the glspUndo action/operation (see photo). Upon further investigation, I don't understand how to implement the handler because the only properties the glspUndo operation has are kind and isOperation. I don't understand how we can undo an operation with that information. I assumed there would be some info about what the last operation/action called was so you could go about undo-ing that operation. Am I missing something?

[tortmayr]

Hi @rileydanejohnston ,

I don't understand how we can undo an operation with that information. I assumed there would be some info about what the last operation/action called was so you could go about undo-ing that operation. Am I missing something?

The client does not keep track of the executed operations, this is the responsibility of the server. So the UndoAction is basically just a trigger notification that the client sends to the server indicating that the last operation should be undone. The server itself manages a Commandstack and can then simply undo the last operation of the stack and send an updated model back to the client.

This feature is currently only available for the Java-based GLSP server. The 1.0.0 Release of the node server does not support this yet. However, commandstack support for the node server is currently under development and already partially available when using the nightly or Release Candidate versions. It will be fully implemented with the upcoming 2.0.0 Release scheduled for end of June.

[rileydanejohnston]

That makes sense to me. Thank you for the response @tortmayr!

[rsoika]

Hi @tortmayr , is this Undo Feature already part of 1.1.0-RC10 ? Or is some example code available somewhere?

[rsoika]

@planger - ok, my model is not a EMF Source model, but I implemented my own BPMNGModelFactory that builds a GGraph from a BPMN file. When the model changed, I typical build an updated gModel and call the method updateRoot from my bpmnModelState:

public class BPMNGModelFactory implements GModelFactory {
  ......
    @Override
    public void createGModel() {
       ......
       modelState.updateRoot(newGModel);
       ....
    }
}

What I did not understand so far: does the modelState now hold all 'revisions' of my models? I do not reset the revision number during an update.

When I do a 'undo' in my modeller, I can see that the 'dirty-flag' goes away, so it seams that something in GLSP is handling something. But currently my model is not visually updated in the diagram plane. So do I need to implement a UndowRedoActionHandler by myself? And what should I do in this handler?

Sorry but it looks like I still missed some basic GLSP concepts.... :-/

[planger]

What I did not understand so far: does the modelState now hold all 'revisions' of my models? I do not reset the revision number during an update.

No the modelState does not automatically keep all your versions of your GModel (and certainly not your source model).

When I do a 'undo' in my modeller, I can see that the 'dirty-flag' goes away, so it seams that something in GLSP is handling something.

I guess the default implementation of the GModelState or rather its CommandStack is leaking this behavior into your implementation, even though it doesn't really make sense in your case, as you are modifying your source model and regenerating the GModel (as is surely the better approach for your use case).

So do I need to implement a UndowRedoActionHandler by myself? And what should I do in this handler?

There are two approaches to implementing undo/redo:

1. Encapsulate every operation into an undoable command and apply the operation on a command stack
2. Keep snapshots of your source model before each operation is applied and reset to that snapshot on undo
3. As option 2, but instead of keeping snapshots, make a comparison between the snapshots and store the difference

Option 1 is more work as you'd have to implement all your operations in a way that they can be undone (ie implementing the inverse operation). This is often achieved by building up your operations based on atomic changes, which are undoable.

Option 2 is less work, but requires potentially a lot of memory for very large models as you'd have to keep each snapshot.

Option 3 is also less work as option 1, but could require CPU, as you'd have to compare your models after each change to derive a patch. This is what the default implementation of the server-node does for JSON models does.

So if possible, I'd go with option 1, which means you'd have to provide Command implementations for your operations, either built up from atomic commands or for each single type of operation. Once you have your commands, your operation handlers can return commands which are then executed by your operation handler on the command stack.

Since the default UndoRedoActionHandler delegates to the modelstate.commandstack for undo/redo already, that should then be sufficient. But of course, you are free to also register a custom UndoRedoActionHandler to handle undo and redo.

[rsoika]

Hi @planger
I did implement option 2 but I have still a problem with the action handler which does not update the visual model plane. My handler simply looks like this:

public class BMPNUndoRedoActionHandler implements ActionHandler {

    @Inject
    protected ActionDispatcher actionDispatcher;

    @Inject
    protected BPMNGModelState modelState;

    @Override
    public List<Action> execute(final Action action) {
        if (action instanceof UndoAction && modelState.canUndo()) {
            modelState.undo();
            modelState.reset();

            return  return Arrays.asList(new RequestBoundsAction(modelState.getRoot()),
                new SetDirtyStateAction(modelState.isDirty(),SetDirtyStateAction.Reason.UNDO));
        }
        logger.warn("Cannot undo or redo");
        return none();
    }

    @Override
    public List<Class<? extends Action>> getHandledActionTypes() {
        return Lists.newArrayList(UndoAction.class, RedoAction.class);
    }

}

My BPMNGModelState handles the model versions and provides implementations of the methods canUndo and undo.

In my BPMNDiagramModule I deregistered the default implementation and registred my handler instead:

...
    @Override
    protected void configureActionHandlers(final MultiBinding<ActionHandler> binding) {
        super.configureActionHandlers(binding);
        ...
        // UndoRedo Handler
        binding.remove(UndoRedoActionHandler.class);
        binding.add(BMPNUndoRedoActionHandler.class);
    }
...

From debugging my code I think my handler works correctly. But my visual model is not updated :-( If I add something in the model than its the first time my model get refreshed visually and I can see that my undo function did restore the old state.
I hopped the returned RequestBoundsAction will do the trick (this was part of the default implementation) but it seems to have no effect in my case.

How can I force my client to refresh the diagram?

[rsoika]

.....looks like I solved the problem by myself.

The trick is to send a UpdateModelAction. This action expects the new GModel. So it is necessary to create the GModel by calling the GModelFactory.createGModel() method directly.

....
    @Override
    public List<Action> execute(final Action action) {
        if (action instanceof UndoAction && modelState.canUndo()) {
            modelState.undo();
            bpmnGModelFactory.createGModel(); // create the new GModel!
            // send an update and isDirty Action!
            return Arrays.asList(new UpdateModelAction(modelState.getRoot(), false),
                    new SetDirtyStateAction(modelState.isDirty(),
                            SetDirtyStateAction.Reason.UNDO));
        }
        logger.warn("Cannot undo or redo");
        return none();
    }
....

And it looks like the ModelSubmissionHandler is exactly for this and if I use this class my action can be simplified to this:

...
    @Inject
    protected ModelSubmissionHandler modelSubmissionHandler;
    @Override
    public List<Action> execute(final Action action) {
        if (action instanceof UndoAction && modelState.canUndo()) {
            modelState.undo();
            return modelSubmissionHandler.submitModel(SetDirtyStateAction.Reason.UNDO);
        }
        logger.warn("Cannot undo or redo");
        return none();
    }

At least the isDirty Action did not work - but maybe this is caused from somewhere else in my own implementation...

[rsoika]

ok, finally I got it - and it was much, much more easy as expected in the beginning.
I don't need a custom UndoRedoActionHandler, I don't need a ModelSubmissionHandler and I don't need to send any additional events.

In my case - where I build the model from a custom source by implementing a GModelState class - the only thing which was needed was to overwrite the methods:

• canUndo()
• canRedo()
• undo()
• redo()

All the rest is handled out of the box by the GLSP core framework. After all this was less then 20 lines of code.

[Adem-Kri]

Hello @tortmayr @planger,

is the handling of undo action now available for the node-based GLSP server ?

[tortmayr]

Hi @Adem-Kri,
yes the new command-based OperationHandler API which supports undo/redo is part of the 2.0.0 release.
We are currently in the progress of finalizing the Documentation Update for 2.0.0.
Once the update is complete you can have a look at the Website Documentation and the project-templates.