Skip to content

Implementing Match Steps

awisema edited this page Mar 11, 2019 · 1 revision

Defining Match Steps

Each match flows through a series of steps as specified by its associated match route, where the steps are represented as states in a simple state machine with the states represented by by instances of sub-classes of MatchDecisions::Base, and the events are user actions.

Each match_decision must be declared in ClientOpportunityMatch via a has_decision declaration. The order of the declarations are used when determining the active step on a match, so it is important to ensure that a step is declared after any steps that might transition to it.

Parts of a Match Decision
State Machine

When a decision is entered, the method initialize_decision! is used to perform any actions including setting the initial state of the machine.

The legal states for a step are declared by the keys of the hash returned by the method statuses. The status back has special semantics, it is defined to un-initialize the current decision, moving back to the previously active one.

Validators are used to determine if a transition to a new state is legal in the current context.

The state of a step is changed by setting the the status attribute of the decision. The transitions between the states are encoded in the nested class StatusCallbacks, and are triggered by the change. If a state change should result in the activation of another step, it will appear here. For example, @decision.next_step.initialize_decision! activates the next step in the flow.