Use metadata in process models to improve maintainability

Thanks @marcel.studer for the detailed and well explained feature request. I've linked 2 more issues, where related topics had been discussed before, and I've also moved the issue into the right project, as this will have to be done in the modeller, not in ECA.

My 2 cents on the idea itself, I'm not so keen about the idea. But I can only speak from our own customer experience here, where we use very specific labels for the elements in a model. We try to keep them short but descriptive in a language which is influenced by the customer's business, not so much by Drupal terms.

Example: instead of calling it "Insert content entity: profile" it is called "After new profile". Or in terms of a condition, the template would call it e.g. [mytoken] not less than [some.other.token], where the customer may think of it in terms of Severity is at least "Critical".

Just making up things to demonstrate the issue.

So, maybe a reasonable playground to meet both sides could be that when a template is being selected, some templated string will be inserted into the name field of that component, if it's still empty at that point. For those who fill in the name before selecting a template, nothing would change. And those who override the name afterwards, they would still be able to do that without that name being changed by some logic afterwards. The only downside of that: at that point, no config fields will be filled yet, so they auto-filled name won't have any of those either.

Thanks @jurgenhaas for taking your time to read my issue and for your detailed response. I fully agree with your point that the models should be well documented and in the language of the business rather than using technical terms.

Just some background why this idea came up in the first place: we are introducing a new software product based on Drupal/ECA and a lot of the ECA process models are provided by the creators of this product. We are starting to create our own models now, and in the future we will have to maintain/alter some of the provided ECA processes. As some of the provided process models were less documented, we had to use the properties dialog a lot in order to understand how these processes work. And some of the provided models were documented in a more technical way. So the idea to use the metadata as a default (using some sort of expert/debug view mode of the model) came up.

But taking your experienced feedback into account, I think we were trying to solve the wrong problem with our idea. Establishing some form of styleguide/best practices/acceptance criteria for provided process models/modeling in general would certainly be more helpful in our scenario. If employees who create ECA process models strive to create well-documented models in the language of the business then it should not be necessary to use the selected template as the default in the name field because every Event/Flow/Action would get a proper name anyway (at least in an ideal world, naming is hard :-)).

I could still see some value in having an option to enable/disable a technical/expert view that would show the metadata in addition to the names/documentation in the business language (faster debugging without having to dig into properties dialogs, both the technical and the business view united in one view). But for me, as a (more or less) novice in terms of Drupal/ECA it is hard to tell whether this would benefit more experienced users so I leave it up to you to decide whether you want to close this issue or not.

In any case, your insights were really helpful and I appreciate the time and effort you have put into this and your very supportive attitute, so thank you very much!

Thanks @marcel.studer for your insights, this is really great to read. And it makes me curious about the product you're about to develop/launch. Hope you can share more details when the time comes.

While reading your reply, an idea hit me as I realized that there is a need that could be addressed in many ways. Some of them are/could be:

• Keep it to the user entirely
• Fill the name field with templates from the backend
• Fill the name field with content from AI
• Fill the name field with some other logic

With that in mind, I'm thinking of a plugin manager, from which site owners can select, which plugin they want to use in their scenario. And then, everybody can write their own plugin to meet their individual needs.

That would require, that we dispatch some events within the bpmn_io UI which will allow us the query the backend to retrieve the name field value from the selected plugin. Such events may include "Template selected", "Property changed", and maybe others.