Maybe an edge case, but if an entity has two fields handling the same workflow, it is not possible with the event being dispatched to find out, wich field was triggered.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | handle-field-name-2982709-6.patch | 2.54 KB | uniquename |
| #2 | handle-field-name-2982709-2.patch | 2.27 KB | uniquename |
Comments
Comment #2
uniquename commentedWith this patch, also the fieldname is passed to WorkflowTransitionEvent. This makes it possible to find out wich field was triggered, if the event is being consumed.
Comment #3
joachim commentedGood call!
I would pass in the field definition, rather than the name string, since everything else being passed in is an object.
Comment #4
uniquename commentedBecause the entity the field belongs to is also passed in, I thought the name is enough to get the field definition from the entity.
Actually I'm not sure, would this save RAM?
Comment #5
joachim commentedThe field definition is probably already loaded and in a static cache somewhere, because the entity is loaded.
Passing in an object means you can type hint, which improves reliability.
Comment #6
uniquename commentedAttached is a patch, that uses the field definition.
Comment #7
bojanz commentedMerging #2931447: WorkflowTransitionEvent should know the transition ID into this issue.
Let's replace $from_state and $to_state with $transition. This matches the intention of the event closer, gives us access to the ID, and makes the signature parallel to that of guards. We can then deprecate getFromState() and getToState(), but keep them functional for BC reasons.
Note that the transition only has getFromStates(), but the actual "from" state can be easily retrieved using $state_item->getOriginalId(), which is what we'll do in the deprecated method. This is generally an edge casey thing to ever need (we tend to care about the transition and the "to" state).
Still unsure about $field_name VS $field_definition. Leaning towards $field_name cause that's what we do in StateTransitionFormInterface and cause I don't see anything else that can be useful in $field_definition.
(Also note that #6 passes the field item, not the field definition. Not the same thing.)
Comment #9
bojanz commentedWent with $field_name, but also added a getField() helper.
Thanks, everyone.
Comment #10
joachim commented> This is generally an edge casey thing to ever need (we tend to care about the transition and the "to" state).
License cares about the from state.
When an order reaches the complete state, you don't know if it's come from draft, or validation, or fulfilment.
Comment #11
bojanz commented@joachim
My guess is that the entire License logic around activation can be replaced with code that reacts to the "order paid" event, now that we have it.
The current logic is an order of magnitude more complex than it was in D7, which is worrying.
Comment #13
joachim commented> License cares about the from state.
Correction: Licenses only care about the from state because the transition ID wasn't previously available, which this issue has fixed:
> My guess is that the entire License logic around activation can be replaced with code that reacts to the "order paid" event, now that we have it.
Yes, that would simplify a few things! I've filed an issue on Commerce License to update code based on new features in State Machine.