-
Notifications
You must be signed in to change notification settings - Fork 6
Implementing 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.
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.