PHPackages                             willdurand/propel-statemachine-behavior - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Utility & Helpers](/categories/utility)
4. /
5. willdurand/propel-statemachine-behavior

AbandonedArchivedLibrary[Utility & Helpers](/categories/utility)

willdurand/propel-statemachine-behavior
=======================================

Adds a finite state machine to your model.

1.0.0(12y ago)3925.1k10[1 issues](https://github.com/willdurand/StateMachineBehavior/issues)PHPPHP >=5.2.4

Since May 21Pushed 12y ago1 watchersCompare

[ Source](https://github.com/willdurand/StateMachineBehavior)[ Packagist](https://packagist.org/packages/willdurand/propel-statemachine-behavior)[ RSS](/packages/willdurand-propel-statemachine-behavior/feed)WikiDiscussions master Synced 3w ago

READMEChangelogDependencies (3)Versions (11)Used By (0)

StateMachineBehavior
====================

[](#statemachinebehavior)

[![Build Status](https://camo.githubusercontent.com/d64b514d783ea7baf74a8e44bcaf046b67c886f29067958b9344996bb22efc78/68747470733a2f2f7365637572652e7472617669732d63692e6f72672f77696c6c647572616e642f53746174654d616368696e654265686176696f722e706e673f6272616e63683d6d6173746572)](http://travis-ci.org/willdurand/StateMachineBehavior)

This behavior adds a finite state machine to your model.

### Configuration

[](#configuration)

```

```

The **state\_machine** behavior requires three parameters to work:

- `states`: a finite set of states as comma separated values;
- `initial_state`: the initial state, part of set of states;
- `transition`: a set of transitions. As you can see, you can add as many `transition` parameters as you want.

Each transition has to follow this pattern:

```
STATE_1 to STATE_2 with SYMBOL

```

A `symbol`, which is part of the Finite State Machine's terminology, can be considered as an event triggered on your model object.

The `timestampable` option can be added to log in `the_given_state_at` column the date when the state is setted

\### ActiveRecord API ###

The behavior will generate the following constants which represent the available states of your object:

- `ObjectModel::STATE_DRAFT`
- `ObjectModel::STATE_REJECTED`
- `ObjectModel::STATE_UNPUBLISHED`
- `ObjectModel::STATE_PUBLISHED`

You can get the current state of your object:

```
getState()

```

Or get an array with all available states:

```
getAvailableStates()

```

Most of the time, you would like to display these states. Thanks to two convenient methods, it's really easy:

```
getHumanizedState() // 'Draft', or 'Rejected', or 'Unpublished', or 'Published'

ObjectModel::getHumanizedStates()
// array(
//  0 => 'Draft',
//  1 => 'Rejected',
//  2 => 'Unpublished',
//  3 => 'Published',
// )

```

The behavior will also generate a set of issers:

```
isDraft()

isRejected()

isPublished()

isUnpublished()

```

But the most interesting part is the implemenation of the FSM itself. First you have methods to determine whether you can perform, or not a transition based on the current model's state:

```
canPublish()

canReject()

canUnpublish()

```

It will also generate a set of methods for each `symbol`:

```
publish(PropelPDO $con = null)

unpublish(PropelPDO $con = null)

reject(PropelPDO $con = null)

```

To handle custom logic, new hooks are created. The methods below should return a boolean value, and can act as **guards** (which is not part of the FSM's terminology).

```
prePublish(PropelPDO $con = null)

preUnpublish(PropelPDO $con = null)

preReject(PropelPDO $con = null)

```

The methods below should contain your own logic depending on each state, and your business.

```
onPublish(PropelPDO $con = null)

onUnpublish(PropelPDO $con = null)

onReject(PropelPDO $con = null)

```

The methods below allow to execute code once the transition is executed.

```
postPublish(PropelPDO $con = null)

postUnpublish(PropelPDO $con = null)

postReject(PropelPDO $con = null)

```

### ActiveQuery API

[](#activequery-api)

To be defined.

### Usage

[](#usage)

Let's say we have a `Post` model class which represents an entry in a blog engine. When we create a new post, its initial state is `draft` because we don't want to publish it immediately. As a `draft`, you can decide to publish your new post. Its state is now `published`. Once `published`, you may want to unpublish it for some reasons. Then, its state is `unpublished`. The last possibily is to republish an `unpublished` post. The new state is `published`.

We have three different states (`draft`, `published`, `unpublished`), and three transitions:

- `draft` to `published`
- `published` to `unpublished`
- `unpublished` to `published`

We can define the following configuration:

```

```

Here is a workflow:

```