Reconsider the structure of separated eca config entities

Created on 9 May 2024, 2 months ago
Updated 12 June 2024, about 1 month ago


Each ECA model currently comes as a pair of 2 config entities: eca.eca.MODEL_ID and eca.model.MODEL_ID

The first config entity contains everything that's required during runtime and is the smallest possible file content so that ECA/Drupal don't have to load the extra data that's only required while editing models. That part (let's call it the proprietary model data) is not needed during runtime and that's why it's "outsourced".

Note: not all modellers have proprietary data, so the second file is optional. But e.g. bpmn_io does need it, as it contains the representation of the model on screen.

Note 2: the eca.eca.* content can be derived from the eca.model.* data, but not the other way round.

Remaining tasks

  • Is this really a good solution?
  • Is it even necessary?
  • If it's necessary, is there a better place to store the proprietary data, e.g. in the key value store?
πŸ“Œ Task






Created by

πŸ‡©πŸ‡ͺGermany jurgenhaas Gottmadingen

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

Comments & Activities

  • Issue created by @jurgenhaas
  • πŸ‡©πŸ‡ͺGermany jurgenhaas Gottmadingen

    Just realized that there is a use case, which needs to be considered when restructuring that: when sharing ECA models with other Drupal sites, or deploying them from one stage to another of the same Drupal site, config management does the job as everything related to the ECA model lives in config. If we were storing the proprietary data somewhere else, it wouldn't go with the model in that context, which is bad.

  • πŸ‡©πŸ‡ͺGermany jurgenhaas Gottmadingen
Production build 0.69.0 2024