L’article explique comment éviter de coder en dur la logique métier dans un projet Symfony en utilisant le composant Symfony Expression Language pour rendre ces règles dynamiques et modifiables sans déploiement de code, en les stockant par exemple dans une base de données ; il décrit l’intérêt de cette approche face à des if/else classiques, présente la création d’une table de règles (action_policies) et un service qui évalue ces expressions dans un contexte donné (ex. utilisateur), tout en permettant d’ajouter des fonctions personnalisées pour étendre la logique.
Tout est dans le titre
Une excellente introduction sur les "expression languages" : tokenizer, parser, evaluator
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Utiliser l'Expression Language de Symfony pour les règles métier... pas bête !
Tout est dans le titre
L'auteur compare l'utilisation de l'Expression Language de Symfony2 avec l'utilisation de Factories pour l'injection de dépendances dans un fichier de configuration.
L'Expression Language de Symfony2 permet d'utiliser une logique dynamique dans la définition a priori plutôt statique des services. Très puissant
Si j'ai bien compris, en utilisant l'"Expression Language" de Symfony2, on peut s'épargner l'injection complète d'un service... et ne prendre que la partie qui nous intéresse.