Skip to content

Workflow, document (best?) practices #9834

Closed
@atrauzzi

Description

@atrauzzi

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 state array 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 single place. This is because I only care about the one value and will regenerate the others from my domain in getState during future checks:
      new Transition(AddonSubscriptionTransition::INSTALL_FREE,
          [AddonSubscriptionState::INACTIVE, AddonSubscriptionState::FREE, AddonSubscriptionState::TRIAL_UNAVAILABLE],
          [AddonSubscriptionState::ACTIVE]),
      
      This kind of implies that I will only use a subject once per load.
    • 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.
  • 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. 😄

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions