Je pense que vous l’aurez compris, sur ce blog on apprécie particulièrement Symfony. 😛
La robustesse et la polyvalence de ce framework (je devrais presque dire écosystème d’ailleurs), nous l’avions déjà évoquée ici Bon, je suppose pour cette fois que le principe que je vais présenter existe aussi dans d’autres frameworks, mais à nouveau, il est vraiment simple à utiliser dans Symfony.
Ce principe c’est le workflow. Si vous avez l’habitude de travailler dans un contexte anglophone, un workflow est tout simplement un ensemble d’étapes sur un projet ou une tâche donné, avec un ordre précis et défini.
C’est exactement la même chose ici, nous allons voir comment définir des étapes prédéterminées dans le flow d’un système.
Je m’explique avec un exemple concret :
Vous travaillez sur un e-commerce et vous avez des commandes qui sont envoyées par colis aux quatre coins du monde (bah quoi ? C’est un exemple, autant être ambitieux 😛).
Cela va sans dire que vos colis sont tous dans plusieurs “états” différents. Ceux en préparation, ceux prêts à être emportés, ceux en cours de livraison et ceux livrés.
C’est ici que le workflow va prendre tout son sens. Votre contrainte principale au niveau du code est simple : un colis ne peut pas sauter une étape, et ne peut pas non plus reculer.
Dans un scénario standard, il faudrait gérer ça avec tout un tas de conditions, pour vérifier qu’à chaque modification d’un colis son état est toujours cohérent par rapport au précédent.
Ceux qui voient de quoi je parle vous devez avoir une multitude de “if” qui clignotent devant vos yeux. 😛
Le Workflow de Symfony va donc vous être d’une grande aide !
Bon, avant de vous expliquer en détails, je vais déjà vous renvoyer vers la documentation de Symfony qui est très bien faite à ce sujet :
Le Workflow est donc un composant de Symfony qui s’installe et se configure comme n’importe quel package/library via Composer et un fichier yaml.
Comme présenté dans la doc on va donc définir des “places” qui vont correspondre à nos différents états de colis puis il faut aussi créer des “transitions” qui comme son nom l’indique vont permettre de passer d’un état à un autre. 🙂
Ensuite ? Et bien grâce aux interactions entre les getters/setters de votre entité et la configuration précédemment définie, Symfony va automatiquement vérifier que ce que vous (ou votre système) essayez de faire est bien possible et autorisé.
Il rejettera donc un passage d’un colis de l’état “en préparation” à l’état “livré”. Il faudra d’abord passer les étapes de “prêt à être emporté” puis “en livraison”.
En allant encore plus loin dans la configuration, vous pouvez également ajouter une notion de droits utilisateurs. Est-ce que seul un administrateur du site est en mesure de dire qu’un colis a bien été livré ? Dans ce cas seuls ceux ayant ce rôle pourront passer cette étape du workflow.
Évidemment, comme bon nombre d’outils proposés par Symfony, l’utilité principale est le gain de temps. Comme je le disais en introduction, fini les multitudes de if ou de if imbriqués pour gérer tel ou tel cas d’usage. Un fichier de configuration simple et une notion d’event listeners suffisent désormais à gérer toutes les sécurités basiques.
Cela ajoute donc aussi une certaine robustesse à votre application et à votre système tout entier. Si les règles changent au cours du cycle de vie de votre projet, il sera facile de réadapter votre workflow. Idem si de nouveaux types d’utilisateurs sont créés, leurs droits pourront être facilement affectés sur chaque point précis. Mais ça, vous devriez déjà le savoir parce que c’est le cœur du composant de sécurité dans Symfony 😛.