bptlab / chor-js Goto Github PK

View Code? Open in Web Editor NEW

146.0 146.0 24.0 4.77 MB

An editor for BPMN 2.0 choreography diagrams based on bpmn-js

License: MIT License

JavaScript 96.17% CSS 3.10% HTML 0.73%

chor-js's People

Contributors

Stargazers

Watchers

chor-js's Issues

Restrict actions on messages

Messages should not be draggable, movable, resizeable, ...

During import of tasksWithMultiplicities.bpmn the warning "multiple DI elements defined for <bpmn:Participant id="Participant_1" />" is created. This should not happen and needs to be fixed in ChoreTreeWalker.js

Split viewer/modeler

chor-js should be exported in two variants (like bpmn-js):

As a pure viewer with only display, selection, etc. capabilities, and
as a modeler with modification and editing features.

This would make it possible to use chor-js purely for visualization as well.

Incorrect event label behaviour for collapsed sub-choreos

Expanded Subchoreos that contain events with labels that are not connected with any sequence flows show incorrect collapsing behaviour for labels of events. Especially if the Sub-Choreos are moved. Labels are either no longer displayed when the Sub-Choreo is re-expanded or labels show outside the collapsed Sub-Choreo. This error is inherited from BpmnJS.
Original expanded Sub:

Same Sub-Choreo after being collapsed, moved and re-expanded (no more event labels)

A different Sub-Choreo, containing one start event, after being collapsed. (Label shows on Sub-Choreo, but should be hidden):

Show make non-initiating for initiating participant of ChoreoTask

Currently it is only possible to make the non-initiating participant initiating, but not the other way around. This makes sense for SubChoreos but not for ChoreoTasks

Configure the (non-)initiating participants of an activity

When selecting a participant band, the user should be able to set it to initiating or non-initiating based on the current state. Attached shapes need to be updated. Also, each activity can only have one initiating participant band, so the other bands might need to be updated as well.

Package choreography library like bpmn.js

Hey there,

I did spike into the code last night and managed to use the choreography library in another project 🎉! Here is how it looked like in the end:

After I managed to do that, I gave the idea of packaging this library like bpmn.js a lot of thought. Here are the steps that have to be taken in order turn the choreography library into an own package:

Create a package.json inside the sub directory (under app)
Note all necessary dependencies in that package.json
Move fonts to this sub directory too in order to include it in the packaged version

That should be the smallest working solution in order to turn the library into a npm package. Anyway, it would be a lot cleaner to move the whole library (sub directory under app) into an own repository. Afterwards you would use git submodules to use the library like you do now.

I will implement the minimal working solution in the next few days and update this thread accordingly. 😊

Support default flows after XOR gateways

One of the outgoing sequence flows following an XOR gateway may be the default sequence flow, highlighted by a small marker. In bpmn-js, this can be set via the context pad:

We can probably adapt most of the code from there.

Items in expanded SubChoreos are not shown after reimporting

How to reproduce:

Create new SubChoreo
Put elements Into SubChoreo
Save bpmn file
Open bpmn file in editor by setting it as xml in app.js
-> Elements added in step 2 are not displayed, however they are (at leas partially) in the .bpmn file.

Disallow placement of elements inside collapsed sub-choreos

When placing new elements, they should not be placeable in collapsed sub-choreos.

Implement text overflow behaviour for participant bands

Participant band should be resized if the text is too long.

Sequence flow disappears after event-based gateway

When a choreo task follows an event-based gateway and any of the elements is moved, the sequence flow disappears. Probably some rule that is not overriden or implemented correctly.

Decide on properties panel

I am personally not too fond of the properties panel. It takes up a lot of space and will make integration into other tools harder. We should evaluate whether we can fit all the functionality we want within popups or the modeler itself instead and get rid of the panel and accompanying code.

Select participant of a band

When selecting a participant band, the user should be able to choose the participant referenced by the band.

A dropdown next to the context pad would be a possible idea.

A participant can not be referenced multiple times by the same task.

Creating new participants should be straightforward. I'm thinking about a + button or something which creates a new generically named participant for the band. The user can then use the familiar rename method to choose a name for the participant.

Change participant multiplicity

Participants can have a multiplicity that is represented by a marker in the band.

This multiplicity should be configurable via the context pad or a popup menu.

All participant bands of the specific participant need to be updated when changing the multiplicity.

"Empty" Diagrams with no items are not imported correctly

How to reproduce:
If all elements from a diagram are removed the diagram is downloaded and reimported, no elements can be placed.

Move selections

When you select multiple shapes and one of them is not movable (e.g., a participant band), the whole selection becomes immovable. It would make more sense to allow a participant band to be moved if the parent shape (the activity) is also selected.

Support for copy and paste

Copy and paste does not work currently. For example, when trying to paste a choreography task:

TypeError: self.canPaste is not a function[Learn More] ChoreoRules.js:213:11
	[38]</ChoreoRules.prototype.init/< ChoreoRules.js:213:11
	unwrapEvent/< CommandInterceptor.js:43:11
	<anonymous> self-hosted:978:17
	invokeFunction EventBus.js:480:9
	[172]</EventBus.prototype._invokeListener EventBus.js:356:18
	[172]</EventBus.prototype._invokeListeners EventBus.js:344:18
	[172]</EventBus.prototype.fire EventBus.js:304:18
	[167]</CommandStack.prototype._fire CommandStack.js:346:13
	[167]</CommandStack.prototype.canExecute CommandStack.js:178:15
	[278]</Rules.prototype.allowed Rules.js:41:14
	[201]</CopyPaste.prototype.paste CopyPaste.js:225:13
	[210]</EditorActions.prototype._registerDefaultActions/< EditorActions.js:101:6
	[210]</EditorActions.prototype.trigger EditorActions.js:173:9
	[221]</KeyboardBindings.prototype.registerBindings/< KeyboardBindings.js:107:6
	invokeFunction EventBus.js:480:9
	[172]</EventBus.prototype._invokeListener EventBus.js:356:18
	[172]</EventBus.prototype._invokeListeners EventBus.js:344:18
	[172]</EventBus.prototype.fire EventBus.js:304:18
	[220]</Keyboard.prototype._keyHandler Keyboard.js:94:19
	<anonymous> self-hosted:976:17

Bundle choreo-js

So I've been thinking about the whole packaging (#36, #35) thing. In the end, we want to have two projects, namely

choreo-js, a package providing the choreography modeler (published on NPM),
choreo-js-demo, a simple frontend loading choreo-js to use it, similar to https://demo.bpmn.io/.

However, this would mean that more or less everything except for the bare frontend stuff (styles, ...) would move to choreo-js.

In particular, this includes tests with their accompanying resources and the linting stuff. As well as all the dev dependencies to karma, chai and whatnot.

@friedow: In your refactor, you left these in the top-level and apparently do not want to put them into the NPM package repo, contrary to how bpmn.js. is structured. Is there a reason for this? Shouldn't tests be performed before publishing the package, and not in the frontend? Asking as someone who has never bundled a package before.

Make choreography tasks draggable

Right now, dragging/moving a choreography tasks leads to errors. It should

be possible to drag and drop choreography tasks, and
the internal representation of the corresponding DI elements should be updated as well.

This will probably need to be done by intercepting the update events in BpmnUpdater.js (bpmn.js) as well as our plugin to that, CustomUpdater.js.

The custom-elements example is probably a good starting place to look at how they did it for their custom elements.

Example Error

unhandled error in event listener EventBus.js:370:6
[36]</BpmnUpdater.prototype.updateSemanticParent@http://localhost:9013/app.js:6581:5
[36]</BpmnUpdater.prototype.updateParent@http://localhost:9013/app.js:6362:3
updateParent@http://localhost:9013/app.js:6145:5
ifBpmn/<@http://localhost:9013/app.js:6687:7
invokeFunction@http://localhost:9013/app.js:23341:10
[128]</EventBus.prototype._invokeListener@http://localhost:9013/app.js:23221:19
[128]</EventBus.prototype._invokeListeners@http://localhost:9013/app.js:23209:19
[128]</EventBus.prototype.fire@http://localhost:9013/app.js:23173:19
[123]</CommandStack.prototype._fire@http://localhost:9013/app.js:21434:14
[123]</CommandStack.prototype._internalExecute/<@http://localhost:9013/app.js:21498:5
[123]</CommandStack.prototype._atomicDo@http://localhost:9013/app.js:21455:5
[123]</CommandStack.prototype._internalExecute@http://localhost:9013/app.js:21486:3
[123]</CommandStack.prototype.execute@http://localhost:9013/app.js:21242:3
[180]</Modeling.prototype.moveShape@http://localhost:9013/app.js:30330:3
[204]</MoveHelper.prototype.moveClosure/<@http://localhost:9013/app.js:32686:5
forEach@http://localhost:9013/app.js:45684:20
[204]</MoveHelper.prototype.moveClosure@http://localhost:9013/app.js:32683:4
[192]</MoveElementsHandler.prototype.postExecute@http://localhost:9013/app.js:31542:3
[123]</CommandStack.prototype._internalExecute@http://localhost:9013/app.js:21505:7
[123]</CommandStack.prototype.execute@http://localhost:9013/app.js:21242:3
[180]</Modeling.prototype.moveElements@http://localhost:9013/app.js:30382:3
MoveEvents/<@http://localhost:9013/app.js:32944:5
invokeFunction@http://localhost:9013/app.js:23341:10
[128]</EventBus.prototype._invokeListener@http://localhost:9013/app.js:23221:19
[128]</EventBus.prototype._invokeListeners@http://localhost:9013/app.js:23209:19
[128]</EventBus.prototype.fire@http://localhost:9013/app.js:23173:19
fire@http://localhost:9013/app.js:27989:12
end@http://localhost:9013/app.js:28076:21
trapClickAndEnd@http://localhost:9013/app.js:28123:5
 EventBus.js:371:6
	[128]</EventBus.prototype._invokeListener EventBus.js:371:6
	[128]</EventBus.prototype._invokeListeners EventBus.js:344:18
	[128]</EventBus.prototype.fire EventBus.js:304:18
	fire Dragging.js:170:11
	end Dragging.js:258:20
	trapClickAndEnd Dragging.js:307:4

Split features module into smaller modules

The features module is getting a bit crowded. We should split it up into smaller modules based on functionality and then bundle them like in bpmn-js/Modeler.js.

Automatic prediction of participants when appending activities

When appending activities or tasks, the default participants of those should be based on the previous task.

Dist directory for bpmn-js fork is not created automatically on install

The dist directory containing the packaged version of the bpmn-js fork is not created when following the install guidelines in README. Thus css and javascript is missing. An additional npm run distro in bpmn-js is required.

Allow changing the loop type of activities

Activities can have a loop type. This should be configurable from the context pad.

Remove unused tests

There's still some tests pertaining to the custom elements stuff in ChoreoModelingSpec.js. Do we still need them?

Refactor CreateChoreoTaskBehavior

This module does not really conform with the style of behaviors as it is tailor made for dragging and dropping a choreo from the side bar. This leads to a bit of dublicated code and a constant exception making for copied choreos. Ideally this would not be necessary.

Collapsing/expanding sub-choreographies

Sub-choreographies should be collapsible and expansible.

If collapsed, a + marker should be displayed.

Make messages selectable

Messages should be selectable, with an optional label and stuff. The issue is that messages do not have a representation in the DI, so the shape would be independent of that. It would probably make sense to have it as a child of the specific participant band.

Constraints in the standard

Read through the standard and identify all modeling constraints posed on choreographies in the text, e.g.,

The Initiator of a Choreography Activity MUST have been involved (as Initiator or Receiver) in the previous Choreography Activity

Inclusive Gateways

We do not currently support inclusive gateways. We should consider them as a feature.

Render choreography task markers

Choreography tasks can have two types of markers that are not rendered yet. The icons can probably be reused from the process diagrams (see bpmnjs/lib/draw/BpmnRenderer.js). The main file to edit would be CustomRenderer.js.

loopType, inherited from ChoreographyActivity:

From left to right: Standard, MultiInstanceParallel, MultiInstanceSequential

See also Table 12.27 in the standard.

Restrict actions on participant bands

Participant bands should not be draggable, movable, resizeable, ...

Autogenerate IDs with factories

We should not generate element IDs on our own with the idGenerator in BandUtil.js. Instead, IDs should be generated by the top-level element/BPMN factories themselves.

Render Participant Multiplicities

participantMultiplicity, attached to the Participant instance. See Chapter 9.3.1 Participant Multiplicity in the standard. If the participantMultiplicity is set, the participant band needs to be extended with the marker shown in the picture.

See also Table 12.33 in the standard.

Use predefined styles in Renderer

Objects in bpmn.js have a slightly translucent background, probably because they use their style repository. We should use the same style for choreography tasks and other elements where applicable.

Screenshot of bpmn.js:

Consistent use of translate functionality

bpmn.js sporadically uses a module called translate, apparently for internationalization.

The module is defined in diagram.js.

translate is supposed to take a string and a set of replacements to translate that string. It does not really do anything and it is not apparent how exactly it is supposed to work. However, to stay "compatible" to bpmn.js, we should consider consistently using it within our codebase.

Make travis-ci use our bpmn-js fork

Travis most likely uses the official bpmn-js package and not the one from our fork. This will lead to problems once we have actual tests.

Render message flows

See also Table 12.33 in the standard.

Choreography tasks can reference a request (initiating) as well as a response (return, optional) message. They are displayed as envelopes attached to the participant band of the source of a message flow with a dotted line.

Model Level

On the model level, they look like this:

Definitions owns the messages themselves.
Choreography owns all the other elements:
- Two participants, a sender as well as a receiver.
- Two MessageFlow elements, one for the request (sender -> receiver) and one for the response (receiver -> sender).
- A choreography tasks referencing the message flows. The order of the message flows in messageFlowRef determines which one is the initiating message flow.

Rendering

As far as I know these attached messages are not represented in the DI model. That means they should always be placed in the middle of the participant band, within a sensible distance.

Attachment

XML of the model example above:

<?xml version="1.0" encoding="UTF-8"?>
<bpmn2:definitions xmlns:bpmn2="http://www.omg.org/spec/BPMN/20100524/MODEL" id="definitions">
  <bpmn2:choreography id="choreography">
    <bpmn2:participant id="sender" name="Sender"/>
    <bpmn2:participant id="receiver" name="Receiver"/>
    <bpmn2:messageFlow id="request_flow" messageRef="#request_message" name="Request Flow" sourceRef="#sender" targetRef="#receiver"/>
    <bpmn2:messageFlow id="response_flow" messageRef="#response_message" name="Response Flow" sourceRef="#receiver" targetRef="#sender"/>
    <bpmn2:choreographyTask id="task" name="Task" initiatingParticipantRef="#sender">
      <bpmn2:participantRef>#receiver</bpmn2:participantRef>
      <bpmn2:participantRef>#sender</bpmn2:participantRef>
      <bpmn2:messageFlowRef>#request_flow</bpmn2:messageFlowRef>
      <bpmn2:messageFlowRef>#response_flow</bpmn2:messageFlowRef>
    </bpmn2:choreographyTask>
  </bpmn2:choreography>
  <bpmn2:message id="request_message" name="Request Message"/>
  <bpmn2:message id="response_message" name="Response Message"/>
</bpmn2:definitions>

Fix export error

Bpmn files should be exportable as .bpmn

Implement Loop Types Sub Choreographies

Support changing event definitions

After placing an event, one should be able to change its event definition.

isExpanded is set on collapsed SubChoreo Shape

isExpanded value should not be set on shape objects. Instead collapsed should be used. This bug might only appear after copying the Choreography.

Add support for boundary events

The standard states that boundary events are allowed in choreography diagrams in principle, without stating how they are supposed to work in practice.

However, the standard failed to add the possibility of attaching boundary events to choreography activities in the metamodel. For that reason, we need to extend the metamodel. I have done it before for another project.

Proposed Metamodel Extension

JSON

let metamodelExtension = {
    "name": "ExtendedChoreographies",
    "uri": "http://hpi.de/ec",
    "prefix": "ec",
    "xml": {
        "tagAlias": "lowerCase"
    },
    "enumerations": [],
    "associations": [],
    "types": [
        {
            "name": "ExtendedChoreographyActivity",
            "extends": [
                "bpmn:ChoreographyActivity"
            ],
            "properties": [
                {
                    "name": "boundaryEventRefs",
                    "type": "bpmn:BoundaryEvent",
                    "isMany": true,
                    "isReference": true
                }
            ]
        },
        {
            "name": "ExtendedBoundaryEvent",
            "extends": [
                "bpmn:BoundaryEvent"
            ],
            "properties": [
                {
                    "name": "attachedChoreographyRef",
                    "type": "bpmn:ChoreographyActivity",
                    "isAttr": true,
                    "isReference": true
                }
            ]
        }
    ]
}

SubChoreos are imported incorrectly. Expanded and Collapsed switch.

Before Export: (B is expanded)

After Importing: (A is expanded)

The generated xml seems to be correct.

Position of direct edit field for choreo task names

When directly editing the name of a choreography task, the field to do so is placed in the top-left corner of the task.

It should really be in the middle somewhere, or at least not overlapping the participant bands.

Removal of choreography tasks

If you try and delete choreography tasks it fails, probably because of the multiple references to the same Participant business object.

Rebind keyboard

The keyboard shortcuts should be rebound to our updated functionality. For example, participant bands should be swapped when using the arrow keys and not moved by pixels.

Relevant files in bpmn-js/features/keyboard.

Fix dead link in README.md

The link to the element support table is broken, or rather the page does not exist anymore. The sentence should be scrapped.

Allow the creation/deletion of participants (bands)

On a global level, participants should be managed. There should be a way to add and remove participants.
On the level of individual choreography activities, one should be able to add or remove participant bands, switch the initiating participant, and attach messages to participant bands.

Challenges

There are a lot of connected elements that need to be updated. For example, when a participant is removed, all the references to them in message flows or activities must be removed.
When creating a participant band, it must be placed within the task in a reasonable spot.

Allow for tolerance with "participantRef"

Some files from external sources might contain "participantRef" instead of "participantRefs".

The standard is unclear regarding this. See pages 322 and 364 in the standard. BPMN20.cmof and Semantic.xsd differ in that regard (https://www.omg.org/spec/BPMN/#docs-normative-supporting). Import should support both options, export should support "participantRef" to be compatible with eclipse and Signavio