The failed tests do not seem to be related to workflow ^^

alternatively, we could consider Registry::getForClass(string $class), checking the supported instanceof strategies (based on its getClassName()) manually

otherwise, i'd argue the usefulness of strategies in general (e.g in favor of mapping by class by design)

otherwise, i'd argue the usefulness of strategies in general (e.g in favor of mapping by class by design)

I agree, but this was asked in an issue / pr

wait, to solve this, isnt it simply matter of adding Registry::getByName(string $workflowName)?

assuming your definitions are "class named" (that's our convention at least). That seems like a much cleaner and explicit approach to me. (To me getting a random workflow, based on "strategies" always seemed like a WTF :))

@lyrixx @ro0NL @simonberger @fabpot
So now, I'm thinking of 3 different path I can take :
1️⃣ I just give up on this consistency dream
2️⃣ I create a new method called getByName in Registry and maybe (or maybe not ?) deprecate get
3️⃣ I create another service called WorkflowRegistry and deprecate Registry

What do you prefer ? Or do you have a 4️⃣ option ?

it should be clear subject (an object) and workflow name (a string) are different things

get and as such strategies expect the subject; the subject is always an object instance. IMHO this shouldnt change (hence i 👎 the PR currently)

a new getByName could return the workflow by name (thus not by subject)

then, if you use "class named" workflows, Registry::getByName(Some::class) will work

I wouldn't change anything. But @lyrixx has the last word.

@ro0NL The workflow name does not have to be unique (among different workflows), right? Not absolutely a showstopper for a getByName method but throws an exception in some scenarios.

The Registry::get(object $subjet) is mandatory. We can not remove / deprecated it. It useful in twig for example.

Then, you should not forget that a subject (doctrine entity or anything else) can have multiple workflows on it.
For example one for the "billing + shipping" and another one for claim.

So getting the workflow by name should not be encouraged.

But your usecase is valid so I'm bit embarrassed by not having a nice solution :/. But I like the @ro0NL idea a lot. We can index all workflows by name (and not by subject FQCN). But you can use the FQCN for the workflow name :)

Do you want to give a try to?

@lyrixx ok, I'll see what I can do.

Actually, I don't think this is a good idea: An object can have many workflow, so getting the workflow by its name does not make sens.

Then, someone has the same need than you and I think #37979 is a simpler / better solution.

WDYT?

@lyrixx

I did not use Definition before so I'm not really familiar with it.

If I understand correctly, Definition is specific to a workflow.
And are you suggesting to go through Definition to get to the Metadata 🤔 ?

How do you inject a specific Definition ? With services.yaml ? Is it possible to inject a specific Workflow ?

I think I don't understand how it helps me. Maybe a PR in symfony-docs might help me :D

And I also have another use case, totally different (and maybe not relevant)
Here is an extract from my code :

$workflow = $this->workflowRegistry->get(new Order());

foreach ($orders as $order) {
    $transitions = $workflow->getEnabledTransitions($order);
    [...]
}

I feel that something more intuitive would be :

$workflow = $this->workflowRegistry->get(Order::class);

foreach ($orders as $order) {
    $transitions = $workflow->getEnabledTransitions($order);
    [...]
}

I can also do something like

$workflow = $this->workflowRegistry->getByName(Order::class);

foreach ($orders as $order) {
    $transitions = $workflow->getEnabledTransitions($order);
    [...]
}

^^

But I probably missed your point, sorry :/ Do you have an example ?

First, you don't need to use the registry to get a workflow. For the record, the Registry has been implemented to be able to get a workflow in twig template. In pure PHP code, I recommend you to inject directly the workflow instance that match your entity.

If you have many workflows, you can use typed + named parameter. For example, with the following configuration, the following services are available:

 Symfony\Component\Workflow\WorkflowInterface $andWorkflow (workflow.and)
 
 Symfony\Component\Workflow\WorkflowInterface $articleWorkflow (workflow.article)
 
 Symfony\Component\Workflow\WorkflowInterface $orWorkflow (workflow.or)
 
 Symfony\Component\Workflow\WorkflowInterface $roundTripWorkflow (workflow.round_trip)
 
 Symfony\Component\Workflow\WorkflowInterface $straightWorkflow (workflow.straight)
 
 Symfony\Component\Workflow\WorkflowInterface $taskStateMachine (state_machine.task)
 
 Symfony\Component\Workflow\WorkflowInterface $wtfWorkflow (workflow.wtf)

This means, I'm able to inject a workflow like this: https://github.com/lyrixx/SFLive-Paris2016-Workflow/blob/master/src/Controller/ArticleController.php#L54 or like this:

class A 
{
    public function __contruct(WorkflowInterface $articleWorkflow)
}

I found the list of available service with the following command:

 bin/console  debug:autowiring workflow

With that in mind, You don't need the registry anymore, and so I think we can close the PR.

A note about the definition (the class that holds the workflow configuration (place + transition + metadata store) and the metadata store (the class that holds all metadata) : You can inject theme in any class. But they are not autowireable.

Your need the following code:

class A 
{
    public function __contruct(Definition $definition)
}

# services.yaml
services:
    App\A:
    parameters:
        $definition: @workflow.article.definition

Note: I found the service to inject thanks to the following command

bin/console  debug:container definition

I hope I solved all your issues and question.

If you learnt new things, may I ask you to open a PR to the doc to explain to others what you learnt ? 🙏🏼 Thanks a lot

@lyrixx
Thank you very much.
I did not know about the typed + named parameter and I did not think about checking bin/console debug:autowiring workflow.

I will update my PR-docs because the injection of Registry is the recommended way in the docs and AFAIK there's no mention of typed + named parameter injection.

Thanks a lot for your efforts. I'm closing this pr. But if you have others questions don't hesitate to ask here