A more expressive way to configure the handling of Workflow transitions

[mathielen]

Description

The Workflow component is great but I am missing an expressive way to define the "handling"-part of a transition.

So, when looking in the workflow configuration, one could see what the actual reaction of a transition is meant to be. Right now you would have to dig into EventListeners and EventSubscribers to find these (if I dont miss anything).

We are using https://github.com/winzou/StateMachineBundle which has a notion of callbacks that describes what services the workflow is calling when a transition was done (after) or is about to do (before). Imho, it is great to see this in the workflow configuration at a glance.

The callback-definitions could be handled by a single config-based EventSubscriber provided by the Workflow component.
Is this something worth considering? If yes, I could try to build a PR for this - when I get the time.

Example

...
transitions:
  process:
    guard: "someGuard.allowedToProcess(subject)"
    from: [pending]
    to: processing
    callbacks:
      enter: "someHandler.doSomething(subject)"
      #ofc, also allow multiple callbacks
      completed:
        - "someHandler.doCompletedTask(subject)"
        - "someOtherHandler.doSomethingAdditionally(subject)"
...

[noniagriconomie]

IIUC, yes you need to list all event listeners/subscribers attached to your workflow event if you attached logic on it
There is nothing done more than marking change if no listeners/subscribers are involved in your transition

You can also leverage the workflow metadata to contextualise your workflow in its config (human explanation for example)

[lyrixx]

Hello, I agree with @noniagriconomie. You are proposing another way to register some listener and usually, we don't like when there many way to do the same thing.

But I understand that having all the things that are related to a workflow is nice!

What about a command that dump all the workflow configuration + all events attached?

[mathielen]

Thanks for your responses, guys.
So I guess, what I was really looking after is a configuration yaml definition and some integration-layer which then would register listeners etc based on this yaml. And it seems like I would just have to build my own as the workflow component will remain a more low-level component and should be kept simple.
For now we will keep using the StateMachineBundle as it seems there is no benefit in migrating to Symfony workflow for us right now.