Hello @meDavid

Before starting on the PR, could you show us how you would configure it / use it. The example don't have to be working, I just want to understand the use case, and how it could work.

Thanks.

Hello @meDavid

Without feedback from you, I will have to close this issue.

Hello @lyrixx
Sorry for the delay. My case is extending the workflow definition without rebuilding the workflow implementation. The workflow definition consists of the places and transitions. The Transitions can be extended, but places are only plain strings, limiting possible extensions.

my_workflow_extension:
  workflow_1:
    places:
      myplace_1: 
        label: 'My Nice label'
        type: 'parallel_gateway'
    transitions:
      transition_1:
        actor: system
        guard_expression: 'some expession with the subject'
        from: myplace_1
        to: myplace_2
      transition_2:
        actor: system
        offset: 'PT3D'
        from: myplace_2
        to: myplace_2

I might also be able to work around it implementing Place.__toString()

@meDavid those additional properties don't make sense for the Workflow component itself. final says that it is a complete concept, there is no need to inherit it. Further, extending Definition means that you will make assumption that the Workflow component must return instance of the your class:

// $definition comes from the component

Assertion::true($definition instanceof FooDefinition);

// ...

The interfaces of the component guarantees to return only Definition. Whenever you assume that it must return FooDefinition, you rely on your insights of the component. It is bad from many aspects. In short, you break encapsulation and it makes harder to maintain component.

However, it doesn't mean that you can't solve your problem. You have transition name, you have explicit mapping transition_name => additional_properties. You always can get them from your own source:

$myPrecious = $this->additionalPropertiesSource->getPropertiesByTransition($transition);

echo $myPrecious->getActor(); // system

I agree with @unkind here.

But anyway, In the PHP part, how would you use theses extra properties (not from the configuration POV, but from the usage POV)

@unkind
Whenever you ask the Symfony WF component for its definition, there is only the certainty that it will implement the Definition interface. I don't assume the Symfony WF component returns my specific implementation but I will provide my specific implementation to the Symfony WF component instead of deriving Symfony WF Defintion from my own Definition implementation.

@lyrixx
Currently I build my configuration using a CompilerPass to create the workflow instances with a Symfony WF Definition that is derived from my own Definition, to make it work. In the compiler pass I also setup the listeners needed for automated transitions (actor=system).

I will provide my specific implementation to the Symfony WF component

How it will affect the component behavior?

@meDavid It looks like the end of your previous message is missing.
I understand how you build the configuration, but I would like to see some usage of your custom Definition class.

@lyrixx After the registration of all the listeners (part op the configuration) we allow to visualize the defintion as with the GraphViz dumper but then one that displays the label and decorates the graphviz illustrating if it is a scheduled/automated/guarded transition. In a job cleanup listener that is fired when leaving a place, the custom definition is used to decide which scheduled transitions need cleaning.

Thanks. I will think a bit about it to see how we could manage it.

Right now, we have at least three options:

• add support for "extra data bag" on the Transition Class and on a new Place class
• add an extension point
• do nothing => ie you move the configuration of what should be done inside the listener. And for the GraphVizDumper, we could leverage the $options parameters to add more information in the dump.

Hello @meDavid

(Sorry for being late on this one)

I'm still not convinced about this use case so I'm not sure we need it in the Component. So I'm in favor of rejecting this feature request as "won't fix".

The Workflow component is quite recent, so we are very cautious about adding new features to it. In any case, if more users complain about this very same thing, we'll reconsider your proposal for Symfony 3.3.
(It already happened ;) )

Thanks!