Decide what to do with TargetInterface

One option is to replace the three add*() methods with the single add() method. It would take some sort of type argument (event, condition, or action for the ECA module). I am not sure how the client module and the API module would communicate about the available types.

Maybe a better model is an event system. When the model is updated (or created or deleted), the API module dispatches an event. The client module subscribes to the event, and decides how to update its config entity.

The current data model uses an Eca config entity and a Model config entity with the same ID. Also, the Model entity has an Eca entity as a class property. As we think about how to decouple from the ECA module, we might decide to change that.

While being on it, there's probably not only 3 but an infinite number of plugin types. While ECA has event, condition, action, and gateway (not fully, though), Migrate comes with source, process, and destination.

But BPMN_io as an example also has groups, and maybe other interesting components, that are currently hidden from the UI because ECA doesn't need them.

For the target interface, we may want to have just one addPlugin method, which gets one argument that tells about the plugin type, which the target module must have registered before anyway.

Ideally, we have the target modules register the plugin types they provide, and the modelers register the components they support, and the modeler API manages the mapping between the plugins and the UI components. Maybe we can achieve that with some metadata that the target module and modeler provide.

All things are fully decoupled now. As part of 📌 Start moving code from the ECA module Active we managed to get everything extracted from ECA and make it available in either modeler_api or bpmn_io, without them having to know anything about ECA.

Automatically closed - issue fixed for 2 weeks with no activity.