Back office

Retour d’expérience suite à un PoC Sylius

Par Olivier A. le 27 mars 2019

Accueil
Back office
Retour d’expérience suite à un PoC Sylius

Lecture 7 minutes

En quelques mots, Sylius se présente comme un « framework » E-commerce, basé sur Symfony et permettant la création de sites marchands facilement personnalisables. Pour cela, la solution embarque les fonctions classiques d’un site e-commerce mais offre en plus la possibilité d'intégrer de nombreux modules et une surcharge facile de tous les composants déjà présents.

Quel est le cadre de ce PoC ?

Un prospect Synolia ayant un projet E-commerce spécifique nous a sollicité pour sa mise en oeuvre. Ce projet, bien qu'il soit e-commerce, a des particularités fortes, auxquelles il aurait été compliqué de répondre avec les solutions E-commerce classiques utilisées par Synolia. Il a été décidé conjointement avec le prospect de se tourner vers la solution Sylius 😊

Le PoC (Proof of Concept) a pour but de valider des points clés du projet afin de confirmer que Sylius est bien LA solution la plus adaptée aux besoins.

En quelques mots, vous avez fait quoi ?

Nous n'allons pas dévoiler l'intégralité du PoC, mais nous allons plutôt nous concentrer sur une fonctionnalité clé qui nous a permis de toucher à plusieurs composants de Sylius.

La but de cette fonctionnalité est que l'utilisateur sélectionne des produits liés à un abonnement qu'il a choisi. Cette sélection doit se faire durant la phase panier, selon le schéma suivant :

L'utilisateur navigue sur les types d'abonnements sur le site
L'utilisateur ajoute un abonnement à son panier et est redirigé vers le récapitulatif de son panier
L'utilisateur saisit son adresse (le comportement classique de Sylius)
Une nouvelle étape est ajoutée pour la sélection des produits disponibles selon son abonnement
La suite du tunnel de commande reprend le natif de Sylius

Pour faire cela, qu'avez-vous altéré sur Sylius ?

Afin de réaliser cette fonctionnalité, nous avons altéré les éléments suivants :

Form (Création d'un nouveau type de formulaire)
Controller (Modification de la méthode addAction du OrderItemController)
Routing (Ajout de routes personnalisées)
Event (Ajouts d'un évènement afin de rediriger l'utilisateur vers le récapitulatif panier)
Templating (Ajout de données à afficher)
State Machine (Ajout d'une étape dans le tunnel d'achat pour la sélection des plats)
Fixtures (Génération de données de test)
Migrations (Modification de la structure de la base de données)
Translation (Ajout des traductions des nouveaux contenus)
Service (Création de services utilisés par le nouveau Controller)

Ce qui représente un éventail assez large

Pouvez-vous m'en dire plus sur la modification du Controller ?

Le Controller que nous devions modifier est le OrderItemController. Pour faire cela il y a uniquement deux étapes à effectuer :

Créer notre class OrderItemController

<?php

declare(strict_types=1);

namespace App\Controller;

use Sylius\Component\Order\CartActions;
use Sylius\Component\Order\Model\OrderItemInterface;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Sylius\Bundle\OrderBundle\Controller\OrderItemController as OrderItemControllerBase;

class OrderItemController extends OrderItemControllerBase
{
    public function addAction(Request $request): Response
    {
        $cart = $this->getCurrentCart();
        $configuration = $this->requestConfigurationFactory->create($this->metadata, $request);

        $this->isGrantedOr403($configuration, CartActions::ADD);
        /** @var OrderItemInterface $orderItem */
        $orderItem = $this->newResourceFactory->create($configuration, $this->factory);

        //...
    }
}

<?php

declare(strict_types=1);

namespace App\Controller;

use Sylius\Component\Order\CartActions;

use Sylius\Component\Order\Model\OrderItemInterface;

use Symfony\Component\HttpFoundation\Request;

use Symfony\Component\HttpFoundation\Response;

use Sylius\Bundle\OrderBundle\Controller\OrderItemController as OrderItemControllerBase;

class OrderItemController extends OrderItemControllerBase

{

public function addAction(Request $request): Response

{

$cart = $this->getCurrentCart();

$configuration = $this->requestConfigurationFactory->create($this->metadata, $request);

$this->isGrantedOr403($configuration, CartActions::ADD);

/** @var OrderItemInterface $orderItem */

$orderItem = $this->newResourceFactory->create($configuration, $this->factory);

//...

}

Informer Sylius qu'il doit utiliser notre classe

sylius_order:
    resources:
        order_item:
            classes:
                controller: App\Controller\OrderItemController

sylius_order:

resources:

order_item:

classes:

controller: App\Controller\OrderItemController

Quelques explications

Les Controllers qui servent à gérer les ressources (Order, Product, ...) de notre application héritent de leur Controller de base (donc notre exemple Sylius\Bundle\OrderBundle\Controller\OrderItemController) qui eux-mêmes héritent tous du Sylius\Bundle\ResourceBundle\Controller\ResourceController, lequel permet de gérer les opérations de CRUD sur les ressources grâce aux fonctions :

showAction : affiche une ressource identifiée
indexAction : affiche une liste de ressources
createAction : affiche le formulaire de création de la ressource et créé la ressource si le formulaire est valide
updateAction : affiche le formulaire de mise à jour d'une ressource et modifie la ressource si le formulaire est valide
deleteAction : supprime une ressource
bulkDeleteAction : supprime une liste de ressources
applyStateMachineTransitionAction : applique une transition de la machine à état sur une ressource

Toutes ces fonctions disposent de :

Une vérification des droits de l'utilisateur avant de faire l'action demandée
Une vérification que la ressource existe (une erreur 404 est levée dans le cas contraire)
Un événement propagé avant chaque réalisation de l'action (par exemple "sylius.order_item.pre_create", "sylius.order_item.pre_delete" et "sylius.order_item.pre_update") qui nous permet d'ajouter un comportement métier très facilement.
Les appels sur l'API REST passent par les Controller. Une modification faite est donc appliquée au Front mais aussi à l'API sans aucune action manuelle, ce qui est très pratique ! Ceci est possible grâce au retour de manière agnostique de toutes les actions des Controllers.

Et en ce qui concerne la machine à état ?

Sylius utilise le bundle StateMachineBundle afin de gérer les états et les transitions entre ces états sur diverses ressources. Nous avons :

sylius_order_checkout : pour le déroulement de l'acte d'achat (du panier à la création de la commande)
sylius_order : pour les états généraux de la commande (du panier à la finalisation)
sylius_order_payment : pour le déroulement de l'acte de paiement (de la création du paiement à la validation par le plugin de paiement)
sylius_product_review : pour le déroulement de la vie d'un commentaire sur une fiche produit (de la saisie à l'affichage en passant par la validation de celui-ci)
sylius_order_shipping : pour le déroulement de la livraison d'une commande (de la demande d'expédition à la validation de la livraison)

Celle dont nous allons parler est sylius_order_checkout. Voici ce que nous pouvons imaginer comme modifications :

Retirer une étape (nous n'avons pas besoin de Livraison dans le cas où nous ne vendons que des produits dématérialisés)
Changer l'ordre des étapes
Fusionner des étapes (par exemple la saisie de l'adresse et le choix du mode de livraison)
Ajouter une étape (afin d'obtenir plus d'informations de l'utilisateur). C'est cette fonctionnalité qui nous intéresse !

Voici donc comment nous avons procédé pour ajouter une étape de sélection de produits liés à notre abonnement :

winzou_state_machine:
    sylius_order_checkout:
        [...]
        states:
            cart: ~
            addressed: ~
            shipping_selected: ~
            shipping_skipped: ~
            product_selected: ~ # l'état ajouté
            payment_skipped: ~
            payment_selected: ~
            completed: ~
        transitions:
            [...]
            select_product: # la transition ajouté
                from: [addressed, shipping_skipped, shipping_selected, product_selected] # états depuis lesquels je peux arriver
                to: product_selected
        callbacks:
            after:
                sylius_process_cart: # ajout de notre transition aux callbacks
                    on: ["select_shipping", "address", "select_payment", "select_product", "skip_shipping", "skip_payment"]
                    do: ["@sylius.order_processing.order_processor", "process"]
                    args: ["object"]
                [...]

winzou_state_machine:

sylius_order_checkout:

[...]

states:

cart: ~

addressed: ~

shipping_selected: ~

shipping_skipped: ~

product_selected: ~ # l'état ajouté

payment_skipped: ~

payment_selected: ~

completed: ~

transitions:

[...]

select_product: # la transition ajouté

from: [addressed, shipping_skipped, shipping_selected, product_selected] # états depuis lesquels je peux arriver

to: product_selected

callbacks:

after:

sylius_process_cart: # ajout de notre transition aux callbacks

on: ["select_shipping", "address", "select_payment", "select_product", "skip_shipping", "skip_payment"]

do: ["@sylius.order_processing.order_processor", "process"]

args: ["object"]

[...]

sylius_shop:
    [...]
    checkout_resolver:
        pattern: /checkout/.+
        route_map:
            [...]
            product_selected: # état que nous avons ajouté
                route: sylius_shop_checkout_select_payment # nous redirigeons vers l'étape suivante.

sylius_shop:

[...]

checkout_resolver:

pattern: /checkout/.+

route_map:

[...]

product_selected: # état que nous avons ajouté

route: sylius_shop_checkout_select_payment # nous redirigeons vers l'étape suivante.

Au niveau de notre machine à état, ce sont les seules modifications que nous avons apporté et celles-ci suffisent à ajouter notre étape.
Pour notre besoin nous avons également modifié les templates et créé un formulaire...

Y-a-t-il d'autres concepts intéressants ?

Oui, Sylius s'appuie sur la plupart des concepts de Symfony ! Et il y en a de très intéressants et souvent utilisés avec Sylius. Nous allons nous pencher sur deux d'entres-eux uniquement.

La décoration :

Dans le cas, par exemple, où nous voudrions modifier la formule de calcul de prix d'une variation de produit définie dans Sylius\Component\Core\Calculator\ProductVariantPriceCalculator, les solutions qui s'offrent à nous sont les suivantes :

Étendre la classe et surcharger la fonction calculate(). C'est impossible : Sylius a défini la classe comme finale.
Copier/Coller la classe entière pour en faire un nouveau service. Dans ce cas, nous dupliquons du code et perdons les potentiels correctifs faits par Sylius.
Décorer la classe originale, c'est la meilleure solution !

Le "decorator pattern" permet de garder le comportement d'une fonction, mais d'ajouter notre propre code métier avant ou après l'exécution de la fonction décorée. Nous pouvons appliquer ce pattern sur beaucoup de services, comme par exemple les Factory.

Les plugins :

Sylius dispose d’un grand nombre de moyens de personnalisation et d’extensions. L'objectif d'un plugin est de compartimenter nos développements en "briques" simples et réutilisables.
Tout ce que l'on peut faire dans notre application (surcharge, création, ...), peut être fait dans un (des) plugin(s). Nous vous conseillons donc de les utiliser. Sylius dispose d'une bibliothèque de plugins que vous pouvez retrouver sur le site officiel.

Pour finir, qu'en est-il de la QA et des tests ?

L'analyse statique de code ainsi que les tests sont très fournis. Le cœur de l'application ainsi que les plugins proposés sont de très bonne qualité. Et les tests ont une très bonne couverture de code.

Voici un petit tour des vérifications faites par la CI (Travis sur le repository officiel) pour les PRs de Sylius :

validate-composer : validation du composer.json et composer.lock
validate-composer-security : vérification de la sécurité des composants installés via SensioLabs Security Checker
validate-doctrine-schema : validation des fichiers de mapping Doctrine
validate-twig : validation de la syntaxe des fichiers Twig
validate-yaml-files : validation de la syntaxe des fichiers Yaml
validate-yarn-packages : validation du package.json et yarn.lock
test-phpstan : analyse statique du code PHP avec PHPStan
test-phpspec : analyse du code PHP (définie par des spécifications) avec PHPSpec
test-phpunit : tests unitaires en PHP avec PHPUnit
test-behat: tests fonctionnels (via la simulation d'un navigateur) avec Behat

De ce fait, la CI est un peu longue, mais elle nous garantie une qualité de code et une non-régression sur nos projets 😊

Olivier A.

A lire également

Retour d’expérience suite à un PoC Sylius

Quel est le cadre de ce PoC ?

En quelques mots, vous avez fait quoi ?

Pour faire cela, qu'avez-vous altéré sur Sylius ?

Pouvez-vous m'en dire plus sur la modification du Controller ?

Créer notre class OrderItemController

Informer Sylius qu'il doit utiliser notre classe

Quelques explications

Et en ce qui concerne la machine à état ?

Y-a-t-il d'autres concepts intéressants ?

La décoration :

Les plugins :

Pour finir, qu'en est-il de la QA et des tests ?

PHP, un épi et des piles

Jeux, IA Act et une checklist pour votre sécurité digitale !

Les bonnes résolutions