- Issue created by @joachim
- 🇩🇪Germany jurgenhaas Gottmadingen
This is already the case. Modeler API needs to manage what's in
entityTypeBuild
because only Modeler API knows about all the context that required to build the collection, i.e. which routes do exist and what permissions are controlling them. This is the case especially when there are multiple modelers available, because that results in pretty complex route management and related stuff.However, you don't lose any flexibility, instead you just don't have to deal with all that repetitive stuff that every model owner plugin would have to do repetitively over and over again.
Modeler API still allows you to own the edit-form route and build your own edit form like you did before. And within that form you can embed a modeler by calling something like this:
$form['canvas'] = \Drupal::service('modeler_api.service')->embedIntoForm($form, $form_state, $entity, 'bpmn_io');
This will embed the modeler at that place, and the modeler API even handles form validation and form submission for that part of your entity edit form, without you having to bother about anything. Your model owner plugin needs to implement certain things in a way that it just deal with that limited scope, but that's pretty straightforward. We had done that for AI Agents originally, where all the metadata, prompts, etc. have been handled by the regular edit form, and all the tool and sub-agent setup has been delegated to Modeler API in an embeded canvas.
- 🇬🇧United Kingdom joachim
The changes that entityTypeBuild does to entity types associated with a model is going to get in the way for Module Builder, which shows multiple forms.
And the extra items in ListBuilder aren't going to be relevant to Module Builder either.