[meta] Replace property panel with Drupal Form API

Provide some settings so that users can switch between the property panels of either Drupal or bpmn_io

Why not just implement it as a separate modeler plugin?

When properly done, guess there's no reason to still use the bpmn property panel, or is there something that would be missing then?

@boromino this could be done with a new modeller plugin. However, the modeller remains the same, it's just using a different UI. This matters because the used modeller is stored with the ECA config entity, and each model can only always be edited with the same modeller. Should we really keep both UI options, or maybe even skip one of the two eventually, then those models should still be editable with that same modeller. Therefore, the implementation would just load different javascript libraries, depending on which UI is being selected. The rest of the implementation remains the same.

@mxh that's correct, we could skip the native UI for the property panel. For several reasons, that's something much later in the process, if ever. Not only does the new UI have to prove its capabilities first, but also the external Camunda desktop client uses the same logic so that we should keep support for that structure anyway. If it turns out that nobody continues using that UI in the bpmn_io modeller any longer, we can turn it off, but it won't be much overhead if we didn't.

Not only does the new UI have to prove its capabilities first, but also the external Camunda desktop client uses the same logic so that we should keep support for that structure anyway.

I think the only way to find out is to directly switch it to the new UI. That way it's more likely that occurring problems are being reported here. It's also worth noting that, when having full Drupal Form API capabilities, only then we are able to substantially improve UX with Ajax'ed dynamic forms and autocomplete suggestions. The other way around just doesn't seem worth it. The bpmn_io modeller could still support the model XML structure as it's doing now, by still storing configuration values there.

Just to be clear, if we replace the property panel by Drupal's form API, the underlying modeller will still continue to maintain its XML structure. Otherwise, the whole canvas of that modeller wouldn't work any more. That's what I meant in the first item of the remaining tasks section:

Build the communication back and forth for events that select another item in the canvas and for changes of field values in the form

That means, when an element in the canvas is selected by the user, we need to hook into that event and build the correct property panel while getting the current values for those properties from the selected element. And when properties get changed in the form fields of the property panel, we need to send them back to bpmn_io which will update the XML model by that.

In other words, this modeller remains the same, except for the property panel.

As part of the modeler API integration and the additional requirements coming from the AI Agents who will use this framework in the future as well, I went back and looked into this topic and got surprisingly far: I'll be able to replace the property panel with Drupal Form API components which will open an amazing set of new capabilities. I will make this optional, so that users can decide whether they want the legacy property panels or the new ones. Maybe we will deprecate the legacy panel eventually, but for now this seem reasonable.

That's great news and exciting!

Do we need to take care about CSRF token protection when opening up for a real form coming from the backend? So far my understanding is that it's needed when the request might involve some write operations. Maybe the CSRF token is already included in the rendered form, but might be worth a double-check to look into.

I had considered that, but we don't need it as the forms will not sure back. We only receive the forms for data input, but the values will be collected in the frontend. Only the save route well write back to drupal, and that's already protected.

Do we get full form API support from this mechanism, including native form validation, submission and Ajax such as autocomplete?

Ajax, autocomplete, states, and wide range of widget is all supported. Form validation is already in place, just not in a way that each individual form gets validated but the values for each individual plugin by using the plugin's validation. That's already in place for ECA 2, but that will have to be moved out of ECA into the modeler API so that all use cases of this framework will benefit from it.

When it comes to full Form API support, I would say we will get pretty close but maybe not 100%, like e.g. multi value fields could probably be a challenge. I guess, we may have to "wait and see" what the experiments with all of this will highlight.

Ok. We may be more flexible when not supporting "BC" to the BPMN's property panel. Currently I see no reason why I'd use BPMN's property panel if I could have all the good stuff of Drupal's form API. Maybe not worth trying to cover both. But that's just an assumption around this, maybe there are good reasons to keep that compatibility I just have missed.

Yeah, performance was a concern to me for a long time. IT's surprising how quick the form loads, though. And I'm even considering to keep forms in the browser, so that we only have to load each form once.

However, the BPMN Property Panel doesn't come with any maintenance effort for us, so we can keep it until we're really certain that everyone will have switched.

For now, it's just a nice infrastructure for development. We can keep the 3.0.x branch functional with the native property panel and can build with the Form API without breaking any of the other development streams.