Decide what to do with TargetInterface

Created on 23 March 2025, 11 days ago

Problem/Motivation

The modeler system in the ECA module (before the 3.0.x branch) is tightly integrated with the Drupal\eca\Entity\Eca config entity type.

As a first step to decoupling from the ECA module, πŸ“Œ Start moving code from the ECA module Active adds Drupal\modeler_api\TargetInterface, and the related πŸ“Œ Remove code that is added to the Modeler API module Active declares that the ECA config entity implements that interface. However, the initial version of the interface is still coupled to the ECA module, with methods addCondition(), addEvent(), and addAction().

This issue is to plan, and perhaps implement, more complete decoupling.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

🌱 Plan
Status

Active

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States benjifisher Boston area

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @benjifisher
  • πŸ‡ΊπŸ‡ΈUnited States benjifisher Boston area

    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.

  • πŸ‡©πŸ‡ͺGermany jurgenhaas Gottmadingen

    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.

Production build 0.71.5 2024