L’article explique comment mutualiser la configuration de quatre CRUDs (Post, Page, Category, Series) dans EasyAdmin grâce à un trait PHP, évitant ainsi la duplication de code. Les entités partagent une structure commune (statut, slug, planification, SEO, Schema.org) mais nécessitent des adaptations mineures, gérées par des branches conditionnelles basées sur leur FQCN. Le code est structuré en onglets (tabs) et ensembles de champs (fieldsets) pour améliorer la lisibilité, tandis que des helpers de visibilité (comme onlyOnForms ou hideOnIndex) permettent d’ajuster l’affichage selon le contexte.
L’auteur détaille l’utilisation de FormField::addTab et FormField::addFieldset pour organiser les champs de manière claire, puis extrait les sections récurrentes dans un trait (ContentFieldsTrait). Une branche conditionnelle gère les champs spécifiques à certaines entités (par exemple, la catégorie pour un Post), tandis que des types de champs comme AssociationField ou ChoiceField avec des enum natifs simplifient les relations et les sélections. L’objectif est de maintenir un code DRY (Don’t Repeat Yourself) tout en restant flexible.
Enfin, l’article mentionne les limites du trait et propose d’extraire certaines logiques en services si la complexité augmente. Il s’inscrit dans une série de six billets sur EasyAdmin, après des épisodes consacrés à l’installation, à la construction d’un menu ou à la sécurisation d’un admin. La méthode vise à éviter la divergence des configurations tout en gardant un code maintenable et lisible.
L’auteur explique que les traits en PHP, bien que pratiques pour réutiliser du code, introduisent des problèmes majeurs : lisibilité réduite (comportement non évident), couplage caché (dépendance implicite aux propriétés protégées), encapsulation brisée et tests difficiles. Plutôt que de recourir aux traits, il recommande la composition, l’injection de dépendances ou des classes dédiées pour des architectures plus propres et maintenables. Un exemple concret montre comment remplacer un trait par une classe explicite (UserNotifier) pour clarifier les responsabilités. Une lecture utile pour éviter les pièges des traits au profit de bonnes pratiques SOLID.
Cet article fait partie de ceux listés dans https://schlitt.info/blog/0784_best_of_posts_for_engineers.html
L'auteur explique en quoi l'utilisation des traits en PHP pose problème, ceux ci étant "statiques" par essence -> Il est impossible d'altérer le fonctionnement d'une des méthodes du trait pour l'un de ses utilisateurs. Au contraire, en utilisant une interface, on peut choisir la classe implémentant le comportement dont on a besoin (dispatch dynamique)
Tout est dans le titre
Un article intéressant, sur PHP, dans lequel l'auteur explore différentes pistes relatives au typage de données récupérées de l'extérieur (bdd, api, etc.)
Il finit par proposer un Trait avec plusieurs méthodes privées utilitaires du style "getInt(array $data, string $key)"
Tout est dans le titre
Tout est dans le titre, sauf que ça concerne PHP
Tout à fait d'accord avec l'auteur :-)
L'auteur souhaite regrouper dans des traits certains comportements communs de quelques tests (utiliser la version la plus récente de la base de données en invoquant des migrations, rendre disponible l'injecteur de dépendances pour ses tests d'intégration) PHPUnit propose une annotation @before qui a l'air de rendre ce service.
L'utilisation des Traits permet de réduire grandement la taille des entités Symfony2, pour peu qu'elles partagent des attributs communs. Ici l'auteur montre comment ajouter simplement un comportement "Timestampable" à des entités Article et Commentaire pour un blog.
Les interfaces et les traits en PHP 5.4 : utilisation