Changing from Modeler to Viewer (and back again)


#1

I want to, after a model has been loaded in the modeler, lock the modeler from user changes (disable user modeling), and also being able to unlock (re-enable user modeling).

In effect, that would be the equivalent to first using Modeler and then user Viewer, and Modeler again - but without having to import the XML every time I lock/unlock.

Disabling modeling actions can occur while having the context-pad and/or popup-menu activated (the menu should be re-rendered or disappear).

My three alternatives I’ve come up

  1. Swapping Modeler with Viewer (not preferred)
  2. Unloading/loading modeling modules, i.e. “destroy” but for specific modules only
  3. Modeling modules can be disabled by a flag/event

I would be happy to provide a PR with any code required to support my use case, but I would appreciate advise on the design and how to best fit the bpmn-js/diagram-js architecture.


#2

I have created a a pull request to support my use case.


#3

Just to understand a bit more about your use case: Why is swapping not an option?


#4

On top of my head…

  1. Swapping requires the diagram to load again --> requires canvas/svg to unload and load another. The user will experience a “flickering” for smaller diagrams and a loading icon for larger diagrams.
  2. The viewer does not support the same type of navigation as the modeler.
  3. I want to user to see a “locked modeler”, i.e. still displaying the palette creates this visual effect (my example hides locked actions, but I’m also considering to gray them out to enhance the effect).

#5

Could also give some background info…

In my use case we have multiple users that could potentially work with the same diagram.
On the long term we would like to support live editing by replicating modeling actions over web sockets.

On the short term, when user A modifies the same diagram that user B is looking at, user B will receive a notification there is a newer version to download, locking the modeler.

Also, if user B makes changes virtually simultaneously, but after A, a concurrency conflict occurs and user B should still be able to see the changes he made as a way of helping him to replicate the same change on the new version (can open a new tab with new version and visually compare the two).


#6

We heard this use-case a few times already.

Also, if user B makes changes virtually simultaneously, but after A, a concurrency conflict occurs and user B should still be able to see the changes he made as a way of helping him to replicate the same change on the new version (can open a new tab with new version and visually compare the two).

The stuff I am always wondering is, why users should have that restriction, as the stuff mentioned in your comment can practically always happen.


#7

You’re right.
Locking the modeler is a temporary solution for us until we have implemented “live editing”. And there is no need for you to support our work-around.

I will abandon my open pull requests and we will implement the feature in a custom build by overriding the relevant modules/functions.

However, some functions can’t be overridden easily, so I will return with a pull request in a couple of weeks that would make necessary changes to make the remaining functions overridable.

I hope that would be acceptable with you.


#8

Sounds good to me. We are always open to make our toolkits more extensible / hackable.


#9

Just wanted to let you know we solved it without any modifications to diagram-js or bpmn-js, but rather adding a module that is hacking a bit on the other modules…
Not really a pretty solution, but at least concentrated to one file so it can easily be removed once we don’t need it any longer.

Thank you for making a great library!


#10

Thanks for being a great contributor and sharing the implementation. :slight_smile:


#11

@nikku how can we have this option in pre-bundled packages?
have you added this option to pre-bundled packages? if yes how should it be used?


#12

If you read the conversation, this option will NOT be included in the default packages.

To include it in pre-bundled packages you need to add it to the module options when initializing the BpmnModeler class.

<script src="bower_components/bpmn-js/dist/bpmn-modeler.js"></script>
<script src="ReadOnly.js"></script>
<script type="type/javascript">
var readOnlyModule =[
  __init__: ['readOnly'],
  readOnly: ['type',ReadOnly]
];
var modeler = new BpmnModeler({ container: 'body', modules: [readOnlyModule] });

Please note that the ReadOnly.js gist is somewhat old now and may not work with the latest bpmn.io release.

Edit: To use it you need to set the readOnly flag

modeler.get('readOnly').readOnly(true);

#13

this readonly methods doesnt work anymore sadly