Accueil » Tous les articles » Magento 2 » Ne plus étendre dans Magento 2

Ne plus étendre dans Magento 2

Une habitude coûteuse

Depuis des années, nous avons pris l’habitude d’étendre un peu tout dans Magento (1 surtout mais 2 également) : Contrôleurs, Blocs… L’introduction de l’injection de dépendances à changé la donne et nous allons faire le tour des principales alternatives qui se présentent à nous. Mais en premier lieu, pourquoi le faire.

L’extension veut dire qu’il faut vérifier la compatibilité de la classe fille avec la classe mère. Cela freine les plus courageux quand il est question de faire un changement de version et entraîne des coûts plus ou moins élevés pour l’évolution du projet vers une version plus récente de Magento ou l’installation d’un nouveau module.

L’extension entend également de faire suivre l’ensemble de la logique de la classe parente dont nous n’avons pas forcément besoin. 

Les outils à notre disposition

Les modèles de vue (ViewModels)

Les modèles de vue permettent non seulement de ne pas avoir à assurer la rétrocompatibilité du code mais également d’avoir des modèles qui ont une certaine logique pour un élément donné et qui peuvent être injectés dans différents blocs. Cela respecte le principe de responsabilité unique (SRP aka Single Responsibility Principle) et permet une maintenance aisée.

On trouve souvent des Helpers pour effectuer ces tâches mais ce n’est pas leur rôle et dans beaucoup de cas, ces classes fourre-tout ont tendance à grossir plus que nécessaire avec les impacts sur les performances qui en découlent. L’avantage du modèle de vue est qu’il ne sera utilisé que pour la vue même dans un projet où plusieurs développeurs vont mettre leur touche personnelle. De plus, il n’a pas besoin d’être appelé dans les templates comme c’est le cas des helpers. L’injection se fait automatiquement grâce à une simple déclaration dans le xml.

Injection

L’extension d’une classe est souvent le résultat d’une réflexion qui emmène à penser que si ça a été fait, ce n’est plus à faire. Mais ce n’est pas toujours le cas. J’ai récemment du changer toute la logique de la mise au panier pour un besoin spécifique. Il n’y a pas si longtemps, j’aurais sans doute étendu \Magento\Checkout\Controller\Cart\Add en modifiant les méthodes idoines. Seulement, j’aurais embarqué beaucoup de logique de l’action parente dont je n’aurai jamais eu besoin puisque mon but était de modifier la logique de base justement.

Qui plus est, les actions ou les modèles dans Magento 2 comptent souvent (toujours) des méthodes privées qu’il faut copier dans la classe fille pour avoir quelque chose qui fonctionne.

Interception

Ils sont au nombre de trois :

  • Avant la méthode (before)
  • Après la méthode (after)
  • Autour de la méthode (around)

Si les intercepteurs avant et après sont peu gourmands en ressource, celui qui entoure la méthode est à utiliser avec parcimonie. Il est possible d’injecter des éléments qui ne sont pas présents dans la méthode interceptée via le constructeur de l’intercepteur. Les gains en terme de compatibilité et de maintenabilité sont énormes.

Les classes virtuelles

Si vous n’avez besoin que de changer que les paramètres de votre classe, vous pouvez utiliser le principe de classe virtuelle de magento. Cela permet de modifier un ou des paramètres, peu importe leur type, du constructeur. Une copie de la classe sera générée au besoin et le paramètre modifié. Il est nécessaire de faire très attention à respecter le type de paramètre.

Conclusion

S’il vous semble nécessaire d’étendre un bloc, il est peu probable que le modèle de vue ne puisse pas faire ce dont vous avez besoin.

Si vous avez besoin de modifier une petite partie de la logique d’une classe, pensez aux intercepteurs.

S’il vous faut modifier une grosse partie de la logique, il est sans doute plus judicieux de partir de 0 pour injecter ce dont vous avez besoin.

Sinon, pensez à utiliser les préférences.

 

Besoin d’aide pour mettre cela en place ?


Publié

dans

, , ,

par

Commentaires

Laisser un commentaire