Description
I've crawled over the ~4 pages of documentation on workflow from the symfony site which have been enough to get me to this point.
Unfortunately, the documentation I link to above focuses strictly on bootstrapping the component. There isn't as much as I'd like to see about any of the ways it its outputs can be used. I'm opening this ticket because while functionally I'm getting the output I desire, I'm in the phase now where I like to reflect on my usage of a new component and inquire about best practices.
I think my most specific thoughts/questions/facts are:
- I am using the
MultipleStateMarkingStore
implementation - When the marking store calls my
getState
method, I'm currently assembling the statearray
based on various bits of information I infer from my domain graph.- Therefore, I do not serialize and store the entire state
array
because some states/places originate from outside my subject (related models). - Currently, my state transitions always transition from a collection of
places
, to a singleplace
. This is because I only care about the one value and will regenerate the others from my domain ingetState
during future checks:This kind of implies that I will only use a subject once per load.new Transition(AddonSubscriptionTransition::INSTALL_FREE, [AddonSubscriptionState::INACTIVE, AddonSubscriptionState::FREE, AddonSubscriptionState::TRIAL_UNAVAILABLE], [AddonSubscriptionState::ACTIVE]),
- When the marking store calls
setState
on my model, I'm only going to interpret the value to determine what data I need to write to the database.
- Therefore, I do not serialize and store the entire state
- So far, I've avoided using events because I feel comfortable interpreting the resultant
setState
call. But should I not be doing that and specifically focusing on using the events API of workflow to act on my data?
So, generally speaking, I'm looking for some anti-pattern advice, but I think some of this might do well to be codified somehow in the documentation so that people aren't inadvertently subverting the intended design of this very useful component!
I might update this description if I dream up better ways of explaining things, I hope you get the gist of what I'm after. 😄