- 🇩🇪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 11:24am 8 February 2023 - 🇨🇭Switzerland boromino
Added #states to form elements on entity loader service and entity load action.
- Status changed to Needs work
over 2 years ago 12:43pm 8 February 2023 - 🇩🇪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 thefrom
field is set tocurrent
? - 🇨🇭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 ofeca_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 foreca_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:
- The form error needs to be set properly. This can probably be achieved with sugesstion mentioned in #10.
- 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 thebuildConfigurationForm
method. - Issue was unassigned.
- Status changed to Active
11 months ago 8:54am 1 August 2024 -
jurgenhaas →
committed d3c1f773 on 3.0.x
Issue #3318507 by boromino, jurgenhaas, mxh: eca_content - "Entity: load...
-
jurgenhaas →
committed d3c1f773 on 3.0.x
-
jurgenhaas →
committed 226f819c on 3.0.x authored by
boromino →
Issue #3318507 by boromino, jurgenhaas, mxh: eca_content - "Entity: load...
-
jurgenhaas →
committed 226f819c on 3.0.x authored by
boromino →
- 🇩🇪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...
- 🇩🇪Germany mxh Offenburg
As long as the
#parents
key isn't incorporated into the states definitions, this may only work for now with thebpmn_io
modeler. But it wouldn't work for any other tool that embeds plugin forms "inline" such aseca_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.