- Issue created by @jurgenhaas
- 🇨🇭Switzerland boromino
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?
- 🇩🇪Germany mxh Offenburg
When properly done, guess there's no reason to still use the bpmn property panel, or is there something that would be missing then?
- 🇩🇪Germany jurgenhaas Gottmadingen
@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.
- 🇩🇪Germany mxh Offenburg
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.
- 🇩🇪Germany jurgenhaas Gottmadingen
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.
