How to ask the server if an action is allowed

Continuing the discussion from Animation continues upon rolling back SubGraphCollapsed transaction:

I would suggest not using GoJS transactions for this purpose, because transactions are supposed to be shorter and more “immediate” than server trips. Instead, let me offer two ways of doing what you want:

####If you want to be optimistic:

Let the action happen, and when its done,

  1. freeze the parts in question (maybe set their movable, copyable, selectable, etc to false, or set the whole Diagram to isReadOnly = true)
  2. send something to the server for checking (X dropped onto Y)
  3. On success or failure, make changes, delete or move parts
  4. unfreeze the parts in question or the whole diagram

A few samples do things like this, allowing parts to drop, checking their validity and if appropriate, deleting them immediately if not.

Do note that you can probably avoid most of that within the JavaScript if you have the information, even if you plan on checking afterwards anyway, for real-time feedback like changing the cursor to not-allowed. For example in the Swimlanes sample:

      // don't allow dropping onto the diagram's background unless they are all Groups (lanes or pools)
      mouseDragOver: function(e) {
        if (!e.diagram.selection.all(function(n) { return n instanceof go.Group; })) {
          e.diagram.currentCursor = 'not-allowed';
        }
      },
      mouseDrop: function(e) {
        if (!e.diagram.selection.all(function(n) { return n instanceof go.Group; })) {
          e.diagram.currentTool.doCancel();
        }
      },

####If you want to be pessimistic:

You could perhaps override DraggingTool.doMouseUp or DraggingTool.doDropOnto or just Diagram.mouseDrop (like in the code example above) in such a way that it effectively always cancels the tool, but also sends a request to the server with whatever relevant data (X dropped onto Y), so every drag ends in a cancel/rollback.

Then, a success callback from the server is what would actually start a transaction, make the changes, and commit them.

A failure callback might do nothing, or display an error message, etc.


Either way, interrupting every transaction with an arbitrarily long wait for confirmation is probably not the best thing to do.