eca_content - "Entity: load" action: Use Drupal states library

Created on 1 November 2022, over 2 years ago
Updated 18 January 2023, over 2 years ago

Problem/Motivation

The "Entity: load" action provides one form with multiple options for loading an entity. Some fields are not relevant, depending on the method chosen to load the entity. These fields may be confusing when having no effect.

Steps to reproduce

Proposed resolution

Use the Drupal states Javascript library to disable the fields that are not relevant. Alternative would be to hide them completely, but this may confuse the user as this could be interpreted as a bug or error.

Bonus: Add a description to the disabled fields, that they got disabled because they are not relevant. This way the user may understand why the fields got disabled.

Drupal states won't have any effect when using the bpmn_io modeller, but they do take effect when using the ECA Core modeller, since that module is using plain Drupal form API.

Remaining tasks

User interface changes

API changes

Data model changes

Feature request
Status

Active

Version

1.2

Component

User interface

Created by

🇩🇪Germany mxh Offenburg

Live updates comments and jobs are added and updated live.
  • Accessibility

    It affects the ability of people with disabilities or special needs (such as blindness or color-blindness) to use Drupal.

Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇩🇪Germany mxh Offenburg

    Adding potential blocker.

  • 🇩🇪Germany jurgenhaas Gottmadingen

    There is no blocking dependency here, not even a dependency at all. The config form for this action should and could be improved with better UX by utilizing all useful features from Drupal's form API is a thing, whether bpmn_io is going to be using this or not. This action is (potentially) used in different contexts, i.e. in eca_cm and maybe other places. If the context is built upon the form API, then improvements to the build form will improve that. Other usage context, like e.g. bpmn.io so far implements configuration by downgrading forms to their current feature set. And that continues to work, even if the form config gets improved here.

    This is important to keep things decoupled from each other moving forward. I treat that as one of the key design decisions for the ecosystem.

  • Status changed to Needs review over 2 years ago
  • 🇨🇭Switzerland boromino

    Added #states to form elements on entity loader service and entity load action.

  • Status changed to Needs work over 2 years ago
  • 🇩🇪Germany jurgenhaas Gottmadingen

    This looks great, only found a couple of improvements and one mistake: the token name is always required.

    In addition to that, I wonder if the field Entity at the bottom of the form should also only be visible when the from field is set to current?

  • 🇨🇭Switzerland boromino

    A form error is triggered if entity type is required, but none is selected. However, I can not get the corresponding form field to be highlighted. #array_parents in \Drupal\Core\Form\SubFormState::setErrorByName() does not seem to match with the entity type form field name.

  • 🇩🇪Germany mxh Offenburg

    I think you can set the form error like the following:

    $form_state->setError($form['entity_type'], $this->t('Select the entity type to load.'));
    The Form API then should take care about properly identifying the form element.

    I took a look into the MR and noticed the following regards the #states instructions:

    name="action[from]"

    It should be noted, that the first key action is coming from the concrete implementation of eca_cm. The Core Modeller module embeds plugin forms, and prefixes them with the type of plugin (event/condition/action). That means, the currently implemented #states instructions may work for eca_cm, but it's not guaranteed that they will work for other modeller implementations. As we haven't a concrete implementation for 🌱 [meta] Replace property panel with Drupal Form API Active yet, I'm currently not able to find a proper mechanic, which guarantees the compatibility across different modeller implementations.

  • 🇩🇪Germany jurgenhaas Gottmadingen

    I took a look into the MR and noticed the following regards the #states instructions:

    name="action[from]"

    It should be noted, that the first key action is coming from the concrete implementation of eca_cm.

    I'd say the plugin config forms should be declared for "standard" usage, i.e. as if it were used directly by e.g. a form in core. If one of the modellers needs to adjust that, it should be the modeller's responsibility to alter the forms.

  • 🇩🇪Germany mxh Offenburg

    To summarize, I think we're fine when following aspects are covered:

    1. The form error needs to be set properly. This can probably be achieved with sugesstion mentioned in #10.
    2. Resolving the parent key problem that was mentioned in #10.

    For point 2, the following approach may work:

    The buildConfigurationForm method of each plugin receives a $form array argument. In that array, eca_cm always passes along the '#parents' key, which contains an array of the parent keys in the form. By extracting the #parents, prepending them to the form input key for each #states entry, you then have the addressed form input. This could be a general mechanic to be applied, because the #parents key is a key concept of Drupal's form API. Meaning, when implementing Drupal form API for BPMN_io, it can also pass along the #parents key to the buildConfigurationForm method.

  • 🇩🇪Germany jurgenhaas Gottmadingen
  • Issue was unassigned.
  • 🇩🇪Germany jurgenhaas Gottmadingen
  • Status changed to Active 11 months ago
  • 🇩🇪Germany jurgenhaas Gottmadingen
  • Pipeline finished with Skipped
    11 months ago
    #259257
  • Pipeline finished with Canceled
    10 months ago
    Total: 65s
    #281137
  • Pipeline finished with Success
    10 months ago
    Total: 445s
    #281138
  • Pipeline finished with Failed
    10 months ago
    Total: 508s
    #281271
  • Pipeline finished with Failed
    10 months ago
    Total: 467s
    #281322
  • Pipeline finished with Success
    10 months ago
    Total: 517s
    #281340
  • Pipeline finished with Success
    10 months ago
    Total: 499s
    #284538
  • Pipeline finished with Success
    10 months ago
    Total: 480s
    #286173
  • Pipeline finished with Skipped
    10 months ago
    #286270
  • Pipeline finished with Success
    7 months ago
    Total: 172s
    #357879
  • Pipeline finished with Failed
    7 months ago
    Total: 387s
    #369858
  • Pipeline finished with Skipped
    7 months ago
    #370416
  • Pipeline finished with Failed
    7 months ago
    Total: 495s
    #372697
  • Pipeline finished with Canceled
    7 months ago
    Total: 132s
    #372831
  • Pipeline finished with Success
    7 months ago
    Total: 476s
    #372833
  • Pipeline finished with Skipped
    7 months ago
    #372942
    • jurgenhaas committed d3c1f773 on 3.0.x
      Issue #3318507 by boromino, jurgenhaas, mxh: eca_content - "Entity: load...
  • Pipeline finished with Success
    about 1 month ago
    #504797
  • Pipeline finished with Skipped
    about 1 month ago
    #504872
  • 🇩🇪Germany jurgenhaas Gottmadingen

    I've finalized the MR and merged it so that people can more easily play with this with the latest 3.0.x-dev release together with the modeler API. A quick video show how this looks like can be found at https://drupal.slack.com/files/U245N8LMC/F08TCR0ANT1/recording-2025-05-2...

  • Pipeline finished with Success
    about 1 month ago
    #504870
  • 🇩🇪Germany mxh Offenburg

    As long as the #parents key isn't incorporated into the states definitions, this may only work for now with the bpmn_io modeler. But it wouldn't work for any other tool that embeds plugin forms "inline" such as eca_cm does. The #parents key is a common form API concept and thus may be worth to be incorporated. For details, see #12.

  • 🇩🇪Germany jurgenhaas Gottmadingen

    The architecture of the framework has meanwhile changed a lot. ECA and bpmn_io don't know each other anymore. They "communicate" through the modeler API such that ECA (or any other complex model owner) tells the modeler API which components and component types they have. Modelers, on the other end, also tell the modeler API what component types they provide, and the modeler API then maps the model owner component types to those of the used modeler.

    The modeler receives the used components and a config form for each of them as individual pieces. That way the modeler can do with them whatever is needed by the modeler. At that point, the modeler can e.g. inject a parent ID, if that's what the modeler requires.

    On the way back, i.e. when a model gets saved, the modeler breaks the model apart and delivers a list of used components and their config to the modeler API, who then maps that back to the model owner, who receives that data and stores it in its config format.

    In that architecture, the modeler doesn't store a model as a complete entity. It just passes components, config and context to the modeler API. The modeler has no knowledge about the meaning or the components or the structure and format of the model as a config entity. That's only known and under control by the model owner, i.e. ECA or AI Agents, etc.

    This decoupled architecture allows every model owner to work with every modeler, as long as both sides support the modeler API.

    Of course, if a modeler only wants to work for e.g. ECA, they can still avoid using the Modeler API, but then they are on their own and need to implement everything themselves.

  • 🇩🇪Germany mxh Offenburg

    Is #21 a reply to #20 or a general information about modeler API? Maybe posted into the wrong issue (looks like an answer regards modeler API)?

  • 🇩🇪Germany jurgenhaas Gottmadingen

    It was indeed meant as a response to #21. In my view, individual config forms from plugins (components) don't require any enhancements that the modeler requires, e.g. parent. As of the described separation between model owner (ECA) and modeler (bpmn_io or cm), the modeler can add stuff that they require without having a plugin to be bothered with enhancements that are not relevant on the component level.

  • 🇩🇪Germany mxh Offenburg

    However, the "#parents" key is a common Form API concept. It's not something special. An implementation based on a certain API is supposed to incorporate its common concepts.

  • 🇩🇪Germany jurgenhaas Gottmadingen

    Sounds great, you explained it in a much better way, but that's what I had in mind ;-)

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

Production build 0.71.5 2024