Depuis Symfony 3.2, un nouveau composant très utile a vu le jour : le composant Workflow. Celui-ci est en effet très pratique et peut très largement simplifier vos développements lorsque vous avez, par exemple, à gérer des workflows de statut dans votre application.
Le but de ce composant
L’objectif de WORKFlow est de reproduire des “machines à état” (ou automate) qui correspond à un modèle de mathématique.
Évidemment, dit comme ça, le composant paraît hyper compliqué. Mais une image vaut 1000 mots :
En bref, le composant Workflow permet de définir plusieurs états pour une entité.
INSTALLATION
Dans tous les cas, vous devez installer la dépendance suivante :
"symfony/workflow": "~3.2@dev"
Si vous utilisez une version antérieure de Symfony mais >=2.3, c’est aussi possible mais il vous faudra également installer ce bundle non-officiel qui embarque le composant et ajoute la configuration nécessaire sous le namespace du bundle :
"fduch/workflow-bundle": "~0.2@dev"
Pensez bien à activer le bundle dans votre kernel.
CONFIGURATION
Il va maintenant nous falloir définir la configuration de notre workflow et ainsi définir les statuts (appelés places) et transitions possibles. Pour cet article, nous sommes partis sur un exemple basé sur les statuts d’une pull request. Celle-ci peut avoir les états suivants : opened
, closed
, needs_review
, reviewed
et enfin merged
.
Cependant, elle ne pourra, par exemple, pas être passée en merged
sans être passée par le statut reviewed
. C’est ici que le composant Workflow prend tout son sens.
Voici ce que donne notre configuration complète :
workflow:
workflows:
pull_request:
marking_store:
type: multiple_state
arguments:
- state
supports:
- AppBundle\Entity\PullRequest
places:
- opened
- closed
- needs_review
- reviewed
- merged
transitions:
feedback:
from: opened
to: needs_review
review:
from: [opened, needs_review]
to: reviewed
merge:
from: reviewed
to: merged
close:
from: [opened, needs_review, reviewed]
to: closed
Nous spécifions ici que nous souhaitons utiliser un workflow de type multiple_state
. Notez que si vous souhaitez utiliser une transition simple d’un statut vers un autre, vous pouvez utiliser ici single_state
. Nous disposons donc également d’une classe AppBundle\Entity\PullRequest
qui dispose d’une propriété state
ainsi que son setter et getter associé (le composant va utiliser les méthodes getter et setter pour changer l’état et/ou obtenir l’état courant) :
<?php
namespace AppBundle\Entity;
use Doctrine\ORM\Mapping as ORM;
/**
* @ORM\Table(name="pull_request")
*/
class PullRequest
{
/**
* @ORM\Column(type="json_array", nullable=true)
*/
protected $state;
public function setState($state)
{
$this->state = $state;
}
public function getState()
{
return $this->state;
}
}
Nous avons terminé, nous pouvons maintenant commencer à utiliser le composant Workflow !
BRANCHEZ-VOUS SUR LES ÉVÉNEMENTS !
Le composant utilise également plusieurs événements, à savoir, dans l’ordre chronologique :
workflow.leave
: lorsque notre pull request va se voir dépourvue de son dernier statut,workflow.transition
: lorsque la transition vers le nouvel état est lancée,workflow.enter
: lorsque le nouvel état est défini sur notre pull request,workflow.guard
: pour vous éviter de rendre la transition possible, vous pouvez utiliser cet événement pour définir votre événement bloqué : $event->setBlocked(true);
Enfin, sachez que ces événements existent aussi en version unique pour chaque workflow afin de vous permettre de vous brancher dessus uniquement sur certains workflows. Il vous faut alors utiliser le nom workflow.pull_request.enter
.
Faisons encore mieux, vous pouvez même vous brancher sur une transition particulière :
workflow.pull_request.enter.needs_review
: permet de se brancher uniquement lorsque nous définissons un nouvel état needs_review
à notre pull request, nous pourrons alors envoyer un email à l’auteur pour qu’il corrige certaines choses,workflow.pull_request.transition.merge
: interviendra lorsque la transition de merge prendra effet sur notre pull request.
Cet Article est utile ? Votez