I'm not sure about this use case. You are mixing the concern here. I mean: You are using the event as a data bag and IMHO this is not the right place do it.

In your example, the tracking number should be a property of the Order. With the new implement, the tracking number is volatile, and IMHO, it's not a good idea.

So for now, I'm 👎 with this PR.

Please read the issue, I have explained why this is a good option to have. Otherwise you split your code related to one logic in half.

I might be agree that parameters could be needed. But I would like to have the opinion of @stof and / or @Nyholm before changing my vote.

Anyway, about the implementation, What about using the GenericEvent ?

Ok, let's add some flexibility here.
But please, Re-use the GenericEvent.

Hello @Padam87

Could you take time to finish this one? If you can't and if you agree, I can push directly into your fork to finish it. Just tell me ;)

Oups. Sorry. I did not see you updated the PR.
Don't hesitate to add a comment when you push something and it becomes "ready for review"

I've read the issue and Im not sure why this is needed.

You are mixing the concern here. I mean: You are using the event as a data bag and IMHO this is not the right place do it.

I agree with this. The workflow component is not a data bag.

I need help to understand why

// Controller.php
if ($workflow->can($order, 'start_shipping')) {
    $workflow->apply($order, 'start_shipping', ['tracking_number' => $trackingCodeService->getCode()]);
}

// EventListener.php
public function onStartShipping(Event $event)
{
    /** @var Order $order */
    $order = $event->getSubject();
    $order->setTrackingNumber($event->getParameter('tracking_number'));
    $this->orderMailer->send(/* ... */) // The mail contains the tracking code
    $em->flush();
}

... is better than:

// Controller.php
if ($workflow->can($order, 'start_shipping')) {
    $workflow->apply($order, 'start_shipping');
}

// EventListener.php
public function onStartShipping(Event $event)
{
    /** @var Order $order */
    $order = $event->getSubject();
    $order->setTrackingNumber($this->trackingCodeService->getCode());
    $this->orderMailer->send(/* ... */) // The mail contains the tracking code
    $em->flush();
}

Just to be clear: I'm still not convinced with this PR. But it does not make the component worst ; that's why I added my vote. But actually it's a +0 ;) If someone is against it, I will change my vote.

Right now Im not convinced that this PR is needed. But it is probably because I do not know the specific scenario that @Padam87 know. =)

There are no specific scenarios here, every example i would give could be solved in another way. (Code in controller, another service, 2 transitions instead of 1 etc).

I think parameters are a nice, uniform way to do all these, and to have every transition related change to the subject done at one place. You guys clearly have a different opinion about this, so closing...

I've read the issue, because I have the same necessity to pass parameters trough the event to the event listener.

Let me explain my use case:
For every successful transition I persist an iteration entity for the subject and this happens in the event listener. Some attributes of the iteration entity should be set only on certain transitions. But without the possibility to add parameters to the event, I can't access them.
I can, of course, create the iteration entity before and set the relative attributes, but that does not occur to me naturally (and because I have to remind me to add this operation before each transition call).

If there are other solutions, they are welcome.

Hi,

our use case for this is the delayed expiration of online articles.

As we manage publishing and expiration through a job queue, expiring an article actually sets it in the state "going offline" and adds an expiration job to our job queue. This is done in the article's workflow subscriber so that we can be sure that as long as we're using the workflow component everywhere in our project, it takes care of adding jobs to the queue and so forth.

Because of different reasons we need the ability to delay these jobs (they actually allow to set an execution time).

As far as I see our options are:

1. Before applying the "expire" transition we set a property in the article
   The knowledge about the jobs our their execution time is nothing the article entity should need to know about. IMHO having a $jobDelay property in the article entity would pollute its model.

2. We use a different transition name like "expire_in_two_hours"
   This would pollute our workflow / workflow graph and would need new transitions for all the different delays we need.

3. Define the delay as meta-data to the transition
   The (meta) information to delay the expiration is something that fits very good as meta data to the actual "expire" transition:
   $workflow->apply($article, 'expire', ['startIn' => \new DateTime('+2 hours')]);
   This would give us full control over the actual delay.

The formal problem here is that standard Petri Nets don't seem to support this. Maybe there are some parallels to colored Petri nets (https://en.wikipedia.org/wiki/Coloured_Petri_net) where markings/tokens can have colors (i.e., meta data). But the meta data we're talking about in this PR is more for a single transition and not the marking store.

But option (1) and (2) both don't feel right. I understand the point of @Padam87: There are other ways to solve this but having that in the Workflow component would make it so much easier, just like the meta data for the definition of transitions already helped us out a lot (e.g., we're using it to restrict certain workflow transitions to specific user roles which is easy to configure and read and works perfectly).

So what would be the best way to solve this? Maybe we're overseeing a good alternative.

Edit:

Just found this: #29146 (comment) (its even using an article as the example).

Seems like a mixture of (1) and (3) and colored Petri Nets (as the marking now holds meta data). I'd still love to leave the article entity out of this but maybe that's the most flexible way of doing this.

Please open a new issue
Thanks