Quelle joie pour moi de revenir à cette vie d’avant qui m’avait tant manquée … Il s’agit ici du deuxième Symfony Live auquel j’assiste, et comme bien des séminaires, j’ai appris pas mal de choses, que j’ai notées, remises au propre, et vous fais partager !
La keynote de Fabien Potencier
Fabien est en forme pour cette nouvelle session ! Pour démarrer le show, il nous fait un retour d’expérience sur un bug qu’il a eu avec Twig. Après une mise à jour des tests des selectors css, il y a eu un problème de « match » avec une expression qui devait figurer dans le code, via preg_match(). Il commence alors une session de debug, pour avoir un détail plus explicite de la source du bug.
S’inclut alors un petit speech sur l’open source, qui consiste à contribuer pour :
– éviter aux autres ou à soi de refaire la même erreur
– éviter à quelqu’un, voire des centaines de gens de réfléchir de nouveau à un problème
Du coup, quick fix, on fork, on ouvre le code, on essaye de faire le changement, on écrit les tests, on les exécute, on pull request et on croise les doigts 🙂 …
Quand il s’agit d’un package, on peut aussi modifier le code et faire un link dans les vendors pour pouvoir tester plus efficacement.
Cependant, ici il s’agit d’une modification dans ExpressionLangage, qui est une sous-partie de Twig. On peut faire mieux que simplement corriger, ou faire une fonctionnalité qui peut poser problème avec d’autres cas de figure. Du coup, Fabien a poussé la réflexion plus loin … On est en PHP8.1 et on supporte PHP7 dans Twig, ce qui pose problème pour la contribution. La solution : travailler sur Twig4 pour moderniser le code. On ouvre les issues, entre autres : résolution des mismatches camelcase vs. snake_case, ne plus avoir de fonctions globales, analyse syntaxique …
En fin de compte : Twig sera intégré en tant que composant de Symfony, Twig4 sera alors nommé Twig6.2 en parallèle à la nouvelle version de Symfony, et changera de namespace.
Mon avis : une bonne mise en bouche, qui m'a poussée à la réflexion quand à certains de mes side projects.
Comment valider de la donnée – Marion Horteau
Ici, Marion nous fait un parallèle avec l’univers de Pokémon. Personnellement, je ne suis pas du tout fan, mais je me suis laissée tenter.
Pour rappel, un validateur est composé d’une contrainte, qui est appliquée à un objet, et elle est appliquée à un validateur. nativement, il y en a une bonne dizaine (que j’ai du bûcher par cœur pour ma certif …).
Mais certaines contraintes ne sont pas forcément liées à un validateur, comme UniqueEntity dans Doctrine.
On valide sur une propriété, dans un formulaire, dans une méthode (getter ou autre), ou sur une classe entière, et soit dans le code, soit lors d’un submit dans un formulaire.
Mais ici on veut faire de la validation dynamique …
Marion propose donc une solution basée sur une API avec des paramètres qui varient.
Dans le contrôleur, on alimente un objet Evolution, avec un attribut Callback. Comme les contraintes sont différentes, on peut en ajouter avec Assert\Collection. InContext permet de rendre la validation récursive.
Pour externaliser les contraintes, elle crée une interface pour les différents types de contraintes. Elle ajoute des tags dans la définition des services. La persistance se fait soit par Doctrine, soit par Json.
Mon avis : dommage que le contexte Pokémon me rebute, mais il s'agit ici d'un avis personnel. L'introduction sur les validateurs natifs est toutefois un peu longuette, j'aurais aimé qu'elle détaille plus en détails cette validation dynamique. Mais intéressant.
Du DDD avec API Platform – Mathias Arlaud, Robin Chalas
Rappelons-le, ce pattern permet une conception tactique et architecturale. le DDD ce n’est pas du RAD, la conception est pilotée par le métier, et ça ne permet pas de développer rapidement.
Petit rappel de l’archi hexagonale : les layers sont des couches où on écrit du code, ils obéissent à la règle des dépendances.
– Couche basse : domaine (models, events, repo, services …)
– Couche application : contient les services applicatifs pour traiter les use-case métier
– Couche infrastructure : porte vers le monde extérieur (controllers, bases de données, caches, vendors …), c’est la SEULE qui aura accès à du code tiers.
Les avantages :
– on préserve l’intégrité de notre domaine,
– le code est d’avantage testable,
– on est capable de repousser les décisions technologiques,
– le domaine est agnostique du contexte utilisé (ligne de commande, terminal, navigateur …)
Dans Api Platform, on peut configurer via ApiResource les opérations, via new Get() et new Post(). Mais ce n’est pas la bonne approche.
Le pattern command bus va nous permettre de reprendre complètement le main sur nos use case métier en faisant appel à nos domaines. Ça implique : Notion de commande (objet PHP) + un handler (service applicatif) + bus (trouver le bon handler pour une commande données) + deuxième bus (query) pour nous permettre de contrôler la manière dont on interagit avec notre domaine.
On manipule entre autres :
– ItemOperations
– CollectionOperations (ça dépend si on a un id dans le chemin) – supprimée dans ApiP3, tout est operation
– Notion de ChainProvide qui fait appel aux autres providers
– On peut créer nos propres providers, qui auront d’autres priorités
– Création de DataTransformers
Mon avis : Haaa ! API Platform ! J'adooore ce framework, et je voulais vraiment en savoir plus sur le Domain Design Development. Je comprends ici que je n'ai pas fait le tour de ce framework, je pense à certains side projects que je définis en DDD, qui font appel à une API crée par ApiP, mais j'ai envie de remanier tout ça. Conférence très interessante qui m'a remise en question. Merci :D !
Doctrine, objet typé, et colonne JSON – Grégoire Pineau
Ici, on parle CMS, notamment celui utilisé par JoliCode. Composé de blocs, qui représentent chacun un objet.
L’objectif de ces blocs :
– éviter la duplication de code
– pouvoir stocker les blocs en BDD
– avoir un maximum d’objets PHP
– et si possible, un objet par type de bloc
Pour ce faire, deux solutions : utiliser l’héritage Doctrine, et stocker du PHP sérialisé.
Les options :
– MappedSuperClass : Doctrine ne sait pas gérer les relations avec
– Single Table (genre une première classe) avec une entité. On aura une entité mais la deuxième classe sera vide, si la première est remplie.
– Class Table : crée une table par type de bloc, pas très pratique à administrer.
On rejette d’emblée le PHP sérialisé via serialize() et unserialize(), non interopérable ! Quand à l’objet stocké en JSON, c’est « so 2013 » …
La solution proposée c’est le Concept Unit Of Work, la donnée est encapsulée via l’EntityManger qui :
– contient le cache de toutes les entitées passées
– gère les écritures en BDD,
– gère les transactions,
– s’occupe de quel objet doit être insert / delete / update
– s’occupe de gérer les dépendances entre les objets
– fait des snapshots des objets qu’il rencontre pour faire un diff au moment du flush.
On utilise alors les event Doctrine, qu’on hooke dans notre code, avec un listener Doctrine.
Mon avis : Je vais me faire taper sur les doigts, mais je vais être franche. C'est assez pénible quand les slides sont passées vite-vite quand on ne connait pas vraiment le sujet (qui ici est spécifique, puisque retour d'expérience). J'ai eu beaucoup de mal à suivre. Personnellement, j'aurais préféré moins de contenu, mais peut-être plus d'explications.
Connaissez-vous vraiment JWT ? – Karim Pinchon
Pour rappel, JWT (prononcé abusivement « jot ») = Json Web Token.
C’est une solution simple et sécurisée, qui a une référence et une valeur.
La cryto, ça obéit à des régles : c’est mathématique, c’est de confiance, ça communique, ça passe sur un canal non sûr, et c’est CAIN.
ça implique :
– la signature numérique
– le chiffrement
– le hachage (intégrité et sens unique)
– Mac / HMac (intégrité et authentification)
– encodage (chaine de caractères)
Pour voir à quoi ça ressemble, il existe les outils token.dev et jwt.io
Après un tour des tokens existants (JWE, JOSE …), quelques conseils :
– attention à ne pas tout accepter côté serveur
– valider les claims
– préférer l’asymétrique
– utiliser une librairie existante et éprouvée
– ne vous battez pas pour révoquer les JWT (ça doit avoir un cycle de vie)
– éviter de logger les jetons (pour la confidentialité)
Mon avis : je suis peu familière avec le cryptage des données, car je n'en ai fait que rarement dans ma carrière, mais c'est bon à savoir.
Des composants Symfony méconnus qui valent le détour – Alexandre Daubois
- HTMLSanitizer : prévu pour SF 6.1, expérimental.
HTMLPurifier : garde au mieux l’arborescence des noeuds, supprime les données potentiellement dangereuses.
Le Sanitizer reconstruit les données du HTML en extrayant les données safe de l’input, la structure de base peut être perdue. Le comportement est défini par HTMLSanitizerConfig. Il peut forcer les https pour les URL, autorise les Schemes, autorise les media hosts. - STRING : arrivé en SF 5.0, il permet de faire de la manipulation simplifiée de codepoints, par exemple des emojis : combinaisons possibles pour faire des couleurs de peau, crée des chaines par contructeur (CodePointString, UnicodeString, ByteCodeString …), crée des chaines par factories.
- OptionsResolver (remplace SPL) : valeurs obligatoires, callbacks, etc … , normalisation pour résoudre les options.
- L’internationalisation : ce n’est pas seulement de la traduction (dates, nombres, monnaies, etc …), INTL depuis SF 2.3 (mai 2013).
International Component For Unicode : quelques entreprises bien connues l’utilisent. Permet de formater : les langues, les locales, les monnaies, les timezones (reprises par les forms, qui vont puiser dans ce composant.)
Mon avis : je connaissais déjà OptionsResolver, mais c'est bien sympa d'en connaitre d'autres ! :D ...