Modeler API: Allow users to switch between the model and the form

There is more to this: if we ever find ourselves with more than one modeler, e.g. bpmn_io and ReactFlow, or whatever, then we get even more options.

What we could actually do is to keep the edit route for using the classic form, and then add operations for each available modeler, e.g. "Edit with BPMN.io", "Edit with ReactFlow", etc. I'm building this into the modeler API just to see if that makes any sense.

OK, I've played with this a bit and I guess this makes sense, but only works on the route /admin/structure/ai-agent where we see the entities and a dropdown for each with the available operations. There we can keep the edit operation with the traditional form, and add more operations from the modeler API as they become available.

Later, if we ever want to get rid of the traditional edit form, we can just disable that operation.

@marcus_johansson are you OK with this approach?

@thejimbirch Can you please update the steps to reproduce?

@anjaliprasannan there is nothing to reproduce, it's a missing feature. I'm already in it.

@jurgenhaas - that sounds like a good solution, we need dropbuttons for /admin/config/ai/agents later that can show the default actions as well, but I'll make a follow up for that when this is done. And in 2.0.0 when plugin agents are gone, we can make this route the default config entity listing route.

This MR is now available for review. It has only fairly little changes but it makes a big difference. Here is what happens:

• Modeler API takes over the routing, permissions, list building, etc. All of this got removed from the AI Agent module and makes that much easier to maintain in the future
• There is no duplicate list in /admin/structure any more
• The agents have a weight and can be sorted
• Agents now also get versioning, documentation, etc. injected by the Modeler API
• The format of the entities remains unchanged
• The Modeler API offer plenty of operations for each entity
• It also offers the add and edit forms that are native by the entity, if the form handlers are defined
• And a lot more, sure I forgot something

With this, the user has the option to either use the form or the modeler, to edit the agents. That was the original purpose of this issue. I've implemented such that it is useful in the long run.

What this means is that modeler_api is now a dependency of ai_agents, but that shouldn't be an issue, because without a modeler (e.g. bpmn_io) installed, nothing changes. The modeler API just offers services as described above, but that looks to the user like if the ai_agents implements that itself, and there is no other overhead involved.

Installing bpmn_io (or other modelers) remains totally optional. Only if the user did that would the extra features become visible and usable.

This approach is really great from a UX point of views, but also DX should be a no-brainer.

Now, we should discuss if this approach has any value, and if so, how far back this should be made available. For now, Modeler API is planned to only support Drupal 11.2 or later, but if we want to use it earlier for AI Agents, we need to change the strategy there. A decision is fairly urgent, because Modeler API is now ready for Beta and should be released soon.

So this was discussed in Slack, for now modeler_api can be a dependency on AI Agents and then when we move to 2.0.0 we will most likely split away so AI config and runner will be in AI Core and any UI or admin tool will be contrib - maybe this module will still exist for that purpose.

In 2.0.0 we will then have to take a decision if we keep the dependency or if the UI part will be completely open to any module without preferences.

So for me this is all good!

OK, that sounds like a great approach: I'll make modeler_api compatible with Drupal 10.4 but not bpmn_io - I think the only part is that I have to add the BC layer for OO hooks. At least I hope that's the case.

Created a related issue 📌 Test to make modeler_api available for Drupal 10.4 Active for that.