Dès que les termes VO ou Value Object ressortent dans une discussion, je constate qu’une remarque revient presque systématiquement : « VO ? » ou encore « VO, tu veux dire un DTO c’est ça ? »

Ces sujets ont déjà été débattus il y a plus de 15 ans, mais certains développeurs « neufs » peuvent parfois ne pas les connaitre (ce qui n’est pas illogique). Je voulais donc faire un billet pour rappeler en quelques lignes de quoi il s’agit.

Notez que très souvent les développeurs utilisent les Value Objects mais ne savent tout simplement pas qu’il y a 15 ou 20 ans, d’autres personnes leur ont donné un nom

Qu’est-ce qu’un Value Object (VO)

Si on reprend la définition de Martin Fowler dans P of EAA :

« A small simple object, like money or a date range, whose equality isn’t based on identity » http://martinfowler.com/eaaCatalog/valueObject.html

Il n’y vraiment pas grand chose à ajouter à cette définition ! Un Value Object est simplement un objet sans identité, c’est à dire un objet dont l’unicité n’est pas déterminée par un attribut du type « Id » (ou autre selon le système de persistance utilisé), mais par simple comparaison de l’ensemble de ses propriétés.

Concrètement ça signifie également qu’un VO n’a pas de vie en dehors de l’objet qui le contient. Il vie et meurt avec cet objet, qui lui, aura sans doute une identité.

L’importance des VOs dans le design du Modèle

En PHP, les VOs étaient très peu utilisés jusqu’à maintenant. Pour la simple raison qu’ils sont compliqués à stocker et à utiliser avec un système de persistance. Il sera par exemple complexe d’effectuer des requêtes avec des conditions sur les propriétés d’un VO.

Ceci est en train de changer (je dis bien « en train », il y a encore du chemin à faire) grâce à l’arrivée d’ORMs qui laissent de plus en plus de libertés aux développeurs dans leur design objet.

Et c’est une grande nouvelle, car les VOs représentent vraiment un outil essentiel pour designer un modèle solide et consistent.

La preuve par l’exemple

J’espère vous le prouvez à travers un exemple très simple (et réaliste) : « Un bout de système de réservation de véhicules de location » (un bout simplifié :p)

Le sujet

Le système propose aux utilisateurs de louer des véhicules sur une période donnée, et en tenant compte des demi-journées. Le prix de la location diminue à partir du 2ème jour. Le prix de la location inclut une distance en kilomètres, et chaque kilomètre supplémentaire sera facturé.

Design basique « à plat »

Ceci est le type de design que nous retrouvons le plus fréquemment.

Avant

Analyse

En analysant le diagramme, il est facile de comprendre pourquoi je parle de design « à plat ». Nous constatons la nature « inflexible » des données ici.

Première chose, à partir du moment où un développeur manipule des données monétaires, un objet Money devrait systématiquement faire partie du design. Je ne comprend d’ailleurs pas pourquoi ce type d’objet ne fait pas partie intégrante de tous les langages.

Manipuler une donnée monétaire n’est pas simplement manipuler un type double. Il s’agit de gérer des arrondis, une devise, et éventuellement des opérations de conversions.

Que se passe-t’il si des doubles se baladent un peu partout dans le code et que le développeur n’applique pas les mêmes règles d’arrondi dans tous les calculs ? Et que se passera-t’il le jour où il est nécessaire de proposer le service dans une autre devise ?

Je pense que vous avez deviné…

En partant de ce principe, nous pouvons extrapoler ces idées aux autres composants du design.

Par exemple, notre métier possède ici des règles particulières sur les dates de réservation. Il ne s’agit pas simplement d’une date de départ et d’une date d’arrivée. Il existe une règle concernant les demi-journées. Cette règle a une influence directe sur le prix de la réservation. Quelle sera la règle pour borner une demi-journée ? Pour borner un ensemble de dates (début et fin) ?

Le design actuel ne laisse entrevoir aucune de ses règles. Comment seront-elles appliquées alors ? Et bien je vous donne la réponse, même si vous la connaissez, un peu partout dans le code, dedans et en dehors de l’objet Booking, dès lors qu’une date de réservation devra être manipulée.

Ceci aura pour incidence d’éparpiller les règles métier, et si ces dernières changent, le système peut facilement devenir défectueux.

De même pour les prix, le prix d’une réservation n’est pas seulement déterminé par un double, factoriser la règle de calcul du prix dans un objet peut s’avérer également payant dans l’avenir.

Pas besoin d’aller plus loin, je pense qu’à ce stade vous avez compris où je veux en venir.

Design « riche » (factorisation et VOs)

Voici maintenant le design que je vous propose pour remplacer le précédent:

Après

Le diagramme parle de lui même. Dès qu’une valeur monétaire entre en jeu un type Money sera retourné. Lors du calcul du prix d’une annonce, l’objet Booking délègue le boulot à l’objet Rental qui lui même le délègue à l’objet PricePack. Les quelques notes vous montrent de quelle manière les différentes règles métier liées aux prix ou aux dates peuvent être implémentées. Si elles changent, un seul objet à modifier et le système fonctionne.

Le design pourrait sans doute être encore amélioré, mais peu importe, le principe est là

Les VOs ne sont pas des DTOs

Je terminerai avec quelque chose d’important à savoir et qui clarifiera sans doute les choses pour certains:

NON UN VO ET UN DTO CE N’EST PAS LA MÊME CHOSE !

Un DTO (Data Transfer Object) a un rôle bien précis dans l’application. Il s’agit d’un objet transportant le maximum d’informations pour diminuer le nombre de requêtes et d’appels de méthodes. Le but est de transférer le plus de données possible en une seule fois.

Je dirais presque (j’ai dit presque) qu’un DTO est l’inverse d’un VO. Un DTO est un objet qui tente d’aplatir au maximum les données, l’exemple très simple de Martin Fowler illustre très bien ce principe: http://martinfowler.com/eaaCatalog/dataTransferObject.html

Alors qu’un VO, au contraire, va servir à enrichir un design par composition.

Ceci étant dit, merci d’avoir lu cet article, j’espère qu’il vous aura apporté quelque chose !

J’aurais une bonne palette de billets à faire sur Symfony 2, ou encore un avis à donner sur l’arrivée de Zend Framework 2, mais cette nouvelle génération de frameworks et les conversations que j’ai avec d’autres développeurs me donnent plutôt envie de parler du fond et non de la forme.

Le fond, c’est à dire les bases d’une architecture objet.

Après plusieurs discussions avec toutes sortes de développeurs, débutants ou expérimentés, je fais le constat que durant ces quelques dernières années, les frameworks PHP ont eu un double effet sur les développeurs. Le premier positif, l’autre plutôt négatif.

Le bon côté de la force

Ce qui est indéniable avec des frameworks tels que Zend Framework ou Symfony (pour ne citer que ces deux là), c’est qu’ils ont réussi à professionnaliser le développement PHP et à redorer le blason du langage.

PHP a souffert d’une mauvaise réputation, et ce pendant longtemps. Et pour cause, ça a toujours été un langage très simple et très permissif. A tel point que beaucoup de « bidouilleurs » ont pu s’auto-proclamer « développeurs ».

Depuis, le langage a beaucoup évolué et sa place dans le monde professionnel et dans la programmation orientée objet est largement méritée. Cette propulsion du langage dans l’entreprise est due aux évolutions du langage lui-même mais aussi en grande partie à l’arrivée de frameworks aboutis revendiquant les bonnes pratiques.

Les développeurs qui ont adopté de tels outils ce sont vus peu à peu, avec ou sans difficultés, ingérer des concepts de programmation objet, parfois avancés, et ce sont habitués avec plus ou moins de compréhension à une certaine gymnastique de développement web.

Si ce phénomène est sans conteste une très bonne chose, il vient aussi avec son lot de « nouvelles mauvaises pratiques ».

Le côté obscur de la force

Il existe donc un mauvais côté à cette élévation intellectuelle du langage, et je pense ne pas être le seul à le constater.

Beaucoup de développeurs se voient ainsi manipuler des concepts objets avancés, et ce parfois sans connaitre le pourquoi du comment. Pourtant, ces concepts existent depuis bien longtemps, les connaitre et les comprendre fait normalement partie de l’éducation d’un développeur objet.

Mais c’est là tout l’art du cerveau humain, c’est d’être capable de produire quelque chose par simple mimétisme jusqu’à ce que ça devienne machinal.

Ces frameworks ont donc habitué les développeurs à appliquer de bonnes pratiques, mais en imposant tellement de règles et une telle application concrète prête à l’emploi, que pas mal d’étapes ont été brûlées au passage.

On peut comparer ça à un chirurgien qu’on aurait tellement habitué à pratiquer une opération complexe, qu’il l’a maîtriserait, mais ne serait pas capable d’opérer une simple appendicite.

Conséquences

Les conséquences de ce phénomène sont simples. Aujourd’hui les frameworks sont devenus si complexes, magiques ou trop peu performants, qu’ils doivent être repensés et développés pour mieux coller aux standards et aux concepts de base.

Et devinez qui en pâtit ?

Les développeurs ont tellement été habitués que maintenant qu’on leur demande de comprendre ce qu’on leur a fait faire sans réfléchir ces dernières années, ils sont perdus. Et cette nouvelle vague de frameworks, qui sont censés être plus simples et plus universels, semblent au contraire bien plus complexes à leurs yeux.

Evidemment c’est un faux semblant !

Retour aux sources

C’est vrai que je donne une note un peu dramatique à tout ça. En fait, je pense que c’est vraiment une bonne chose, et ce que je vois c’est que les développeurs qui prennent conscience de tout ça donnent une nouvelle dimension à leur métier, et se découvrent de nouvelles passions.

Je n’ai jamais vu autant de développeurs PHP acheter des livres sur les design patterns que ces derniers temps. Hallelujah ! Je dis enfin, car la plupart de ces concepts existent depuis les années 1990 :p

Quoi qu’il en soit, cette nouvelle génération de frameworks est excitante et ça me motive à écrire des billets sur les bases de la programmation objet ! Ce billet fera d’ailleurs figure d’introduction.

Addendum

J’aimerais préciser que je fais évidemment une généralisation concernant les développeurs. Tous ne sont pas concernés par ce que j’écris et certains ont acquis tous ces concepts depuis bien longtemps. Ce n’est donc pas à prendre pour argent comptant, chacun y verra son compte et se reconnaîtra ou non

Heureusement, je pense pouvoir dire sans trop me tromper que le framework est entré dans une véritable phase de stabilisation et que la core team et les contributeurs travaillent d’arrache pied pour l’arrivée du Symfony Live 2011 à Paris.

Ce qui me permet de démarrer une série d’articles sur Symfony 2, dont la première partie concernera le MVC tel qu’il est introduit dans le framework.

Introduction

Une introduction logique pour analyser l’implémentation du MVC et de suivre le parcours d’une requête HTTP.

Un gros travail de documentation sur le framework est en cours et je vous invite vivement à lire les différents guides, regroupés maintenant dans une section intitulée « Book », et deviennent donc des chapitres, qui plus qu’une simple documentation de référence, expliquent de façon simple et accessible (si vous maîtrisez l’anglais bien entendu) les différents concepts derrière la philosophie et les composants et/ou bundles de Symfony 2. Il y a une continuité dans les sujets, c’est très appréciable pour de la doc.

Concernant notre requête HTTP, si ce n’est pas déjà fait, je vous recommande avant de continuer, de lire ce chapitre : The HTTP Spec and Symfony2 Fundamentals, qui est d’ailleurs le premier chapitre, c’est bien, jusque là nous restons logiques !

Cheminement d’une requête HTTP : diagramme

Le chapitre pré-cité étant très bien écrit, je n’ai rien à y ajouter, d’autant plus que ça ne serait pas mieux raconté que part un développeur concerné.

Je vous propose par contre de découvrir le cheminement d’une requête HTTP dans Symfony 2 sous forme de diagramme, plus ou moins un Workflow. Sachant que je n’ai pas respecté de règles particulières pour faire cette représentation, et que je ne peux malheureusement pas tout détailler. Mais si vous êtes comme moi, et que vous aimez avoir un schéma sous la main, servez-vous.

Symfony 2 - Cheminement d'une requête HTTP

Un framework « agnostic »

Pour apporter un peu de précisions sur le diagramme, j’attire votre attention sur la forme agnostic du coeur du framework. Une implémentation du MVC est proposée, mais vous constatez qu’elle est totalement indépendante de la gestion de la requête HTTP, et pourrait être très facilement remplacée.

Comme l’explique très bien la documentation, le coeur du framework propose simplement une série d’objets permettant de manipuler facilement une requête et une réponse HTTP (HttpFoundation).

Autour de ces composants, les opérations sont orchestrées par le gestionnaire d’événements (Event Dispatcher), qui va notifier à ceux qui écoutent ces événements (listeners) que c’est le moment d’intervenir. Ils vont donc altérer tour à tour l’objet de réponse (Response).

Grâce au conteneur de dépendances, il apparait très clairement que nous pouvons détacher n’importe qu’elle partie, pour la remplacer par une autre. D’ailleurs à ce sujet, vous constatez que je met en avant des implémentations concrètes de certaines briques, notamment le routage et la résolution du contrôleur et de ses paramètres. Sachez que le coeur du framework ne propose la plupart du temps que des interfaces, voir des implémentations très génériques, et que les implémentations ne font pas partie des composants du core, mais sont dans le bundle FrameworkBundle. Je cite celles-ci car c’est le fonctionnement par défaut, et celui que la plupart d’entre vous devrait adopter.

Mais il serait donc très simple de ne conserver que le coeur du système, et de créer votre propre framework MVC. Pour ça, il « suffit » d’implémenter les différentes interfaces (contrats), et de connecter des listeners sur les différents événements clés.

Note : il serait également possible de remplacer le HttpKernel par votre propre version, à condition de respecter certaines règles, même si, comme ça, je ne vois aucun intérêt particulier à faire ça.

Evénement core.view

Certains se poseront peut-être la question de l’utilité de l’événement « core.view », qui est dispatché si un contrôleur n’a pas retourné d’objet de type HttpFoundation\Response.

Dans Symfony 2, la création de l’objet de réponse est explicite, c’est au contrôleur de le créer, de le nourrir avec ce qu’il veut, par exemple le résultat du rendu d’une vue/template, et de le retourner.

J’espère ne pas me tromper en disant ça, mais certains contributeurs se sont plains de ne pas avoir une véritable couche « Vue », et j’oserais croire que cet événement permettrait à qui veut, de créer sa propre couche présentation, du moment qu’un objet réponse est fournit en retour. Si quelqu’un veut préciser ce point, il est le bienvenu

Addendum

Je précise que ce diagramme n’est pas du tout officiel, et que je ne suis pas à l’abri d’une erreur. C’est une première version, je ne doute pas qu’elle sera améliorée. Tous vos retours seront très appréciés.

J’ai décidé volontairement de détailler certaines parties du Worflow et d’autres non, pour ces dernières, il faudra fouiller le code

Comme vous le savez, je suis un gros consommateur de Zend Framework, il y a une explication à celà. Lorsque je me suis décidé à adopter un framework PHP, mes choix s’étaient réduits à deux prétendants, Zend Framework et symfony. Alors pourquoi j’ai choisi ZF ? La réponse est très simple, pour sa flexibilité.

Bien que symfony premier du nom soit un très bon framework, il souffre malheureusement d’une rigidité trop importante. Pour résumer grossièrement, je dirais qu’avec symfony, soit on fait tout avec le framework, soit on ne fait rien (ce qui n’est pas nécessairement une mauvaise chose). J’avais besoin d’un framework qui me laisse la liberté d’implémenter tout ce que je peux imaginer. D’autant plus qu’à ce moment là, les frameworks PHP étaient loin de proposer tout l’arsenal nécessaire, et il était évident que j’allais avoir une surcouche de code importante.

Ensuite, je crois que la force de Zend a été de mener une campagne de communication plutôt efficace, et j’avoue avoir été séduit.

Mais ce n’est pas pour autant que je m’enferme dans un outil sans me soucier de ce qui se passe autour. Je surveille de très près l’évolution de PHP et son éco-système. J’essaie autant que possible d’effectuer une veille régulière et j’ai toujours quelques expérimentations en cours

Au delà de ça, je me nourris de tous les concepts qui gravitent autour du développement web, qu’ils viennent de frameworks JAVA, .NET, Ruby ou autre et m’en inspire beaucoup pour nos développements autour de Zend Framework.

Mais voilà qu’est annoncé Symfony 2, depuis maintenant une dizaine de mois (ça passe vite !), et quelle était ma surprise quand j’ai vu que tout ce que j’attendais (ou presque) d’un framework PHP abouti était sur le point d’être intégré dans Symfony 2.

Entre promesses et réalité, où en est-on aujourd’hui et pourquoi Symfony 2 est-il si prometteur ? Je vais tenter de répondre à cette question dans ce billet qui fera office d’introduction à ce nouveau framework.

On casse tout et on recommence

Je suis persuadé que la meilleure initiative a été de tout remettre en question.

Pour proposer un framework flexible, il faut que son cœur soit lui même flexible et conçu dans cette optique. Il doit être léger, simple et suffisamment intelligent pour permettre aux développeurs de laisser aller leur imagination et ne pas se retrouver bloqués par une trop grande rigidité du framework. Il n’y a rien de plus frustrant qu’avoir des idées mais ne pas pouvoir les mettre en œuvre correctement.

Avec Symfony 2, Fabien Potencier a pris le parti de tuer la magie (« kill the magic ») et d’emprunter et utiliser moins de concepts mais de manière plus efficace. Tout a été repensé et ré-écrit « from scratch ».

Une nouvelle orientation était aussi de vouloir transformer un objet requête en un objet réponse (qui j’entends dire « Ha ben oui, c’est logique en fait ! » ?).

Je ne pourrai malheureusement pas faire l’analogie avec symfony 1 car je ne le connais pas assez, mais ce n’est pas très grave étant donné que Symfony 2 n’a plus rien à voir, sauf dans sa philosophie (Fabien).

Pourquoi Symfony 2 est-t-il flexible ?

Je ne vais pas détailler tous les composants du framework mais plutôt me concentrer sur les trois grandes composantes de l’architecture de Symfony 2 qui en font un noyau simple et flexible.

Injection de dépendances

De tous les concepts utilisés en programmation, celui qui me manquait le plus dans les frameworks PHP était l’inversion de contrôle (IOC) ou dans sa forme spécifique l’injection de dépendances. Pour pallier à ce manque j’ai écrit un conteneur très léger de dépendances pour Zend Framework (incomplet) en espérant voir arriver un jour un conteneur abouti au sein des frameworks.

Mon souhait se réalise puisque Symfony 2 repose entièrement sur un conteneur de dépendances léger, puissant et simple à utiliser. Ce composant indépendant, de Sensio, existait déjà mais les frameworks n’étaient pas étudiés pour ce type de pratique. L’utilisation du conteneur n’avait alors qu’un intérêt limité. Dans Zend Framework 1, le coeur du système ne permet par exemple pas d’injecter certaines dépendances qui sont fortement liées. Ou encore l’utilisation abusive du pattern Singleton et l’accès statique à certains objets sont une contrainte limitant fortement la flexibilité du framework.

Dans Symfony 2 le conteneur de dépendances est utilisé dans le coeur du framework et tout est pensé pour un découplage total des composants. Ceci apporte en plus d’autres avantages, tout est par exemple plus explicite, il est très facile de connaitre les dépendances d’un composant en jetant un oeil à la configuration du conteneur.

Pour parler du conteneur lui même, baptisé tout simplement « Dependency Injection », il est très simple à utiliser et permet tout type d’injection (par mutateur, par constructeur, etc.). Je ne rentre pas dans le détail dans ce billet et vous laisse consulter le site officiel du composant pour vous familiariser avec son utilisation.

Je citerai juste au passage la possibilité de « dumper » le conteneur et la liberté d’implémenter son propre driver de configuration (loader). Le premier point est très apprécié et permet de visualiser facilement le graph des dépendances des objets, ce qui facilite vraiment le débuggage

Le système de Bundle

Le succès de symfony 1 est en partie dû à sa communauté et notamment à la possibilité de partager des plugins. Il était logique que Symfony 2 conserve cet aspect. Mais la réflexion a été poussée et les petits gars de chez Sensio nous servent un système qui fait preuve d’une très grande flexibilité.

Derrière le nom « Bundle » qui peut être assez déroutant se cache un système modulaire très bien maîtrisé. Une fois le terme accepté (je suis peut-être fou mais j’ai eu du mal), c’est un régal pour le développement.

La documentation officielle assimile un bundle à un plugin, non pas un module, et à raison. En effet, un bundle dans Symfony 2 est totalement indépendant, mais est surtout très facile à intégrer au sein de l’application. Il suffit de coller le dossier du bundle dans l’application, d’ajouter sa configuration à l’environnement et ça roule tout seul.

Mais toute la puissance de la solution vient du fait que dans Symfony 2 tout est bundle, même les fonctionnalités du cœur sont réunies dans plusieurs bundles dont le chargement est explicite. Tout est donc modulable !

Ce point pourra d’ailleurs perturber certains d’entre vous car même la couche web est un bundle. Et c’est là que nous faisons la différence entre un module, un plugin et un bundle et que l’arrivée d’un nouveau terme prend du sens.

Pour ce qui est du partage, le coup est déjà prévu puisqu’une pré-version du site http://symfony2bundles.org/ est disponible et permet déjà de trouver quelques bundles intéressants. Le site renforce l’aspect collaboratif puisqu’il est en intéraction direct avec github et facilite la participation au développement d’un projet ou d’un bundle.

A noter que le site est réalisé à l’aide de Symfony 2 et Doctrine 2 et qu’une API est déjà disponible pour accéder aux données des bundles et de leurs développeurs. Une bonne vitrine donc

Le dispatcheur d’événements (Event Dispatcher)

Troisième atout dans l’architecture de Symfony 2, une implémentation nouvelle du pattern Observer pour le composant Event Dispatcher.

Un des problèmes les plus difficiles à résoudre en programmation lorsque plusieurs développeurs travaillent en parallèle sur différentes fonctionnalités d’un système est de permettre l’intéraction des différents composants sans avoir à les modifier pour qu’ils puissent fonctionner ensemble. Plus difficile encore, un plugin peut intervenir à différents moments de l’exécution d’une application.

Imaginez par exemple que vous souhaitez modifier l’objet requête avant que votre action de contrôleur soit exécutée. Ceci doit être réalisable sans avoir à mettre la main dans le code du contrôleur. D’autant plus que ce code aura peut-être été écrit par un autre développeur.

Le pattern Observer permet de résoudre ce problème, et Symfony 2 nous propose une implémentation simple et efficace. Une classe Event permet de créer des événements identifiés par une chaine de caractères unique et de lui assigner des attributs eux aussi identifiés par une chaine. Il sera donc inutile dans la plupart des cas de créer une classe spécifique pour vos événements.

Pour connecter un « listener » à l’événement c’est trivial, il suffit de créer une instance du dispatcher et d’utiliser une méthode connect qui prend en paramètre le nom de l’événement, une méthode de callback à exécuter au moment de la notification et un ordre de priorité.

Il existe trois manières de notifier l’événement, que je ne détaillerai pas ici, mais si nous reprenons l’exemple du contrôleur et de l’objet requête, lors de la construction de l’objet réponse à partir de l’objet requête, le cœur du framework utilise la méthode de notification filter() qui demande à tous les « listeners » connectés à l’événement de filtrer la valeur donnée (ici un objet Request) et de la retourner (filtrée). Très facile donc d’altérer l’état de l’objet avant de le récupérer dans notre action de contrôleur. Et ceci en toute transparence.

Symfony 2 nous permet donc de créer très facilement des « Hooks » (le terme est peut-être plus parlant pour certains d’entre vous) et le framework permet déjà d’intervenir à certains moments clés de l’exécution de la requête.

Vous me direz que ceci n’est pas nouveau, Zend Framework 1 permet par exemple de créer des plugins de contrôleur ou des aides d’action, mais ceci reste très spécifique. Un dispatcheur générique tel que dans Symfony 2 permet une ouverture plus grande puisqu’il pourra être utilisé par n’importe quel objet et à tout moment, selon vos besoins.

Autres éléments intéressants

Je me concentre sur les trois éléments clés de l’architecture du framework mais il en existe quelques autres intéressants et renforçant encore la flexibilité.

• la structure du projet (dossiers) : la structure proposée offre une meilleure séparation des différents éléments de l’application, la configuration, la couche web (MVC) et les différents plugins (bundles) fonctionnels.
• le chargement automatique des classes : un seul fichier php utilisant une classe UniversalClassLoader permet de configurer de manière explicite tous les espaces de noms ou les préfixes (PEAR) des différentes sources tiers.
• une classe de bootstrap (AppKernel) unifiée : encore une fois la classe de bootstrap de l’application permet de charger explicitement les différents bundles et la configuration de l’environnement.

Le mot qui revient souvent est « explicite », et ce n’est pas pour rien. Tout est limpide, et il faut mettre les doigts dans le code pour configurer certaines parties du système (« convention over configuration »), ce qui permet d’avoir au passage une vue d’ensemble de ce qui est exécuté au moment de l’initialisation de l’application.

Et les performances ?

Encore une fois c’est une surprise. Symfony 2 est rapide, je dirai même très rapide.

« Kill the magic »

Je citais en début d’article le leitmotiv « kill the magic ». Dans les premières versions de Zend Framework et symfony, il y avait beaucoup de « magie ». C’est à dire que beaucoup d’éléments étaient accessibles de manière obscure pour économiser du code et limiter le nombre de caractères à saisir par ces paresseux de développeurs (ok je me moque un peu).

Le problème est que la « magie » a un coût assez élevé en performances. L’utilisation abusive des méthodes magiques __call, __get, __set, etc. demande une introspection du code et des fichiers importante, ce qui a impact très négatif non seulement sur les performances mais aussi sur la qualité et la compréhension du code.

Les développeurs de Symfony 2 ont pris le parti de tuer cette magie et de rendre les choses plus explicites et moins obscures pour les utilisateurs du framework. Ceci améliore non seulement les performances de manière significative mais adoucit aussi la courbe d’apprentissage du framework car tout y est beaucoup plus clair et compréhensible pour les développeurs. D’une pierre deux coups.

Utilisation interne du cache

Symfony 2 utilise beaucoup de cache (fichiers) en interne et notamment pour la configuration.

Lors de l’exécution de la première requête, certaines classes dépendantes de la configuration sont « compilées » (ou plutôt « empilées » ) en PHP dans le cache. Lors des exécutions suivantes, le cache sera utilisé. Pour vous donner une idée, sur une application de type « Hello World », la première requête prendra 600ms et toutes les suivantes 25ms.

Certains autres composants utilisent abondamment le cache, comme Twig (moteur de templates) ou Doctrine (ORM), et le résultat est indéniable, l’impact sur les performances est énorme.

C’est donc un bon point pour Symfony 2 car le développeur n’aura pas à se soucier de ces problématiques et à intégrer sa propre gestion du cache pour cette partie de l’application.

Le conteneur de dépendances

Je reviens sur ce composant qui a également un impact positif sur les performances.

Grâce au conteneur, les éléments sont chargés à la demande, seulement quand nécessaire (lazy loading). Ceci réduit considérablement le nombre de classes chargées dès l’initialisation du système. C’est vrai pour le cœur du framework mais aussi pour vos propres développements.

Autres atouts

Je ne peux malheureusement pas trop m’étaler, cet article est déjà très long.

J’ajouterai simplement que certaines couches de Symfony 2 sont inspirées de très bons frameworks tels que Spring (JAVA) ou Django (Python) et que certains concepts que nous n’avions pas encore dans l’univers PHP font leur apparition.

Je pense notamment à Twig, le moteur de templates livré avec le framework, qui est très prometteur. J’ai d’ailleurs écrit une intégration du moteur pour Zend Framework 1, et nous (anonymation) allons migrer la couche présentation de certains de nos projets sur ce système.

Je pense aussi à des composants spécifiques, par exemple le composant « Form » pour la gestion des formulaires, qui intègre un data binder pour mapper automatiquement les valeurs d’un formulaire HTML sur un Objet PHP. Ou encore la couche de sécurité pour l’authentification et la gestion des droits des utilisateurs qui est nouvelle (en PHP) et puissante. Et j’en passe…

Tout est également « testable » et l’intégration des tests unitaires et fonctionnels a été simplifiée et renforcée. Rappelons que la pratique des tests unitaires en PHP est très récente, c’est donc une bonne chose que les frameworks professionnels encouragent les développeurs vers de telles pratiques en leur proposant des outils adaptés.

Pour finir, Symfony 2 intègre des outils facilitant le développement et qui ont fait le succès de symfony premier du nom. La debug bar, des exceptions travaillées et plus explicites, des logs, et bien sûr une commande CLI très utile.

Où est l’anguille ?

Jusqu’ici on pourrait croire que j’ai été soudoyé par Sensio pour vous expliquer combien Symfony 2 est merveilleux. Il n’en est rien !

Le framework se montre vraiment très prometteur, mais (et oui), j’ai bien sûr quelques réticences envers certains éléments.

Lorsque j’ai vu apparaître certains concepts dans Symfony 2, j’ai sauté de joie, mais malheureusement rien n’est jamais parfait ou comme on le voudrait.

Je pense par exemple au « data binder » dont l’implémentation est exclusive au composant « Form ». J’aurais aimé voir apparaître un composant dédié à cette tâche qui puisse être utilisable dans d’autres contextes qu’un formulaire HTML. J’ai essayé d’aborder le sujet sur le groupe de discussion mais sans succès. Je sais ce qu’il me reste à faire

Autre chose que je n’aime pas, l’intégration trop poussée de certaines librairies tiers, comme Doctrine 2 par exemple. C’était vrai également pour symfony 1. Lorsque des nouvelles versions de ces librairies sont disponibles il faut compter sur la réactivité du développeur du Bundle en question pour bénéficier de l’intégration des nouvelles fonctionnalités. Mais ce point est discutable car une telle intégration apporte aussi des avantages ; dans le cas de Doctrine, pas besoin de jongler par exemple entre les lignes de commandes de Symfony et de Doctrine, tout peut-être fait par la CLI de Symfony.

Je n’ai malheureusement pas encore assez de recul pour apporter d’autres critiques, mais ça ne saurait tarder. Sans compter que le framework est encore en phase de développement et que certaines choses peuvent encore changer d’ici la première version stable prévue pour Mars 2011.

Conclusion

Vous l’aurez compris, je suis séduit. Sensio nous propose un framework très mature et très bien fichu. Une grosse réflexion a été menée sur le fond et ça se ressent dès les premières utilisations.

Je peux déjà vous dire que chez anonymation nous avons adopté Symfony 2 et nous prévoyons déjà la migration de certains « gros » projets sur le framework.

Mais attention, ça ne veut pas dire que j’abandonne Zend Framework. Certains projets démarrent encore sur ZF et j’attends avec impatience la refonte du MVC prévue pour Zend Framework 2 dont je suis de près le développement.

Je m’excuse pour la longueur de cet article, mais je vous promets que je me suis retenu de rentrer dans le détail sur certains points Cet article fait office d’introduction et d’autres articles plus techniques et spécifiques seront publiés au fur et à mesure de mes aventures.

Edit : Je me rend compte que je n’ai pas du tout parlé de PHP 5.3 mais évidemment Symfony 2 tire profit de toutes les nouveautés du langage. Il n’est d’ailleurs compatible qu’avec PHP 5.3.2 et supérieur. Les conventions sont respectées, les espaces de noms propres. Vous verrez même certaines utilisations des closures plutôt ingénieuses. Je tenais à préciser ce point important.

Le constat est très mitigé, après des heures et des heures sur le code, voilà ce que j’en tire.

Globalement

L’outil est très inaccessible. Pas de documentation efficace, une grosse communauté mais très peu réactive (aucune réponse sur les forums sur des questions critiques). Des heures et des heures de recherche, le plus souvent dans la source, pour réussir à s’en sortir en ayant toujours à l’esprit : « Est-ce que je ne suis pas en train de prendre des raccourcis ? »

Ceci n’enlève pas la qualité du produit mais joue beaucoup dans la décision finale. Développer avec Magento, c’est long. Ça sera difficile pour la plupart des développeurs, et ne parlons même pas des néophytes. Pour créer un module, accrochez vous. Vous passerez par des phases enchantées mais aussi par des phases de déprime totale

Par contre, si vous n’avez aucune spécificité technique particulière, vous aurez entre les mains un outil qui excelle dans la gestion d’une e-boutique. L’installation standard contient déjà la plupart des modules nécessaires à une boutique robuste : gestion de multiples « vues » (pour le multilingue par ex.), attributs des produits très flexibles, gestion des promotions, des newsletters, très bons outils de reporting, etc. etc.

D’un point de vue technique

Modèle de données EAV

L’organisation des données dans Magento repose sur le modèle EAV, acronyme pour Entity-Attribute-Value. Ce modèle de données permet de définir des entités dont le nombre d’attributs peut être très vaste et scalable. Ceci grâce à une séparation de l’entité et de ses paires attribut/valeur. En théorie, ce modèle de données est relativement simple.

En base de données, l’entité est stockée avec très peu d’attributs. La plupart du temps une clé primaire, des clés étrangères, et quelques attributs universels (par exemple la référence d’un produit).

Les attributs sont stockés dans une table commune à toutes les entités (liées par clé étrangère) qui contient tout type d’information : identifiant, nom, label, type (int, char, etc.), certaines contraintes (pour la validation par ex.).

Les valeurs sont souvent stockées dans des tables spécifiques avec comme clé étrangère l’identifiant de l’attribut. Mais pas toujours, dans des implémentations simples du modèle EAV les paires attribut/valeur peuvent être stockées dans la même table.

Sur le papier c’est très prometteur. Mais en pratique ça devient vite impraticable. Cette modélisation rend le code beaucoup plus difficile à déchiffrer. Les requêtes deviennent très complexes en plus d’être très coûteuses en ressources (beaucoup de jointures).

Bien que très flexible, cette modélisation est pour moi une manière de pervertir une base de données relationnelle. Et dans le cas de Magento, le modèle EAV force MySQL à se comporter d’une façon pour laquelle il n’est pas du tout prévu.

Mais qu’il en soit ainsi, les développeurs de Magento ont choisi la flexibilité par dessus la simplicité. Ce n’est pas nécessairement une mauvaise chose, mais vous êtes avertis

L’implémentation du modèle EAV dans Magento est très poussée, il faut chercher dans beaucoup de tables pour une seule entité mais le modèle objet rend heureusement les choses plus faciles. Mais attention, il faut éviter le plus possible d’avoir recours à des requêtes SQL pures, sinon je vous promet qu’il vous manquera quelques cheveux à la fin de l’exercice !

Architecture de Magento et qualité du code

Ce sujet est très sensible. En tant qu’architecte et développeur web averti, je reste dubitatif.

L’architecture du système regorge de bonnes idées, parfois ingénieuses, mais leurs implémentations laissent parfois un arrière goût d’anti bonnes pratiques. Mais globalement je dois avouer que je suis surpris par la réflexion qui a été menée sur ce projet. Je ne m’attendais pas à quelque chose d’aussi poussé.

La vue dans Magento

Magento propose une implémentation particulière de la couche présentation (vues) du modèle MVC.

Dans une implémentation classique, le contrôleur prépare le modèle et le donne à la vue qui n’a plus qu’à afficher les données correctement formatées.

Dans Magento, la vue elle-même est décortiquée en une architecture particulière. Tout repose sur un système de layout regroupant des « blocks » qui sont des portions de vue autonomes. Si on ferme les yeux sur les conséquences en termes de performances, cette modélisation est une véritable surprise.

Le contrôleur prépare toujours le modèle mais ne le passe pas à une vue. Il le stocke simplement dans un « registre » que chaque block pourra ensuite consulter pour récupérer les données nécessaires à l’affichage.

Une vue est un regroupement de blocks dont l’organisation est définie par un fichier XML, le layout.

Un block est un objet autonome totalement découplé du système qui peut être inclus dans n’importe quelle page du site et à n’importe quel moment. Il est composé concrètement d’une classe contenant des méthodes accessibles directement depuis un « template » (vocabulaire Magento pour le fichier phtml) qui met en forme le block (code HTML).

Si on essaie grossièrement de faire l’analogie avec une application Zend Framework classique, on peut dire que l’objet block est un regroupement d’aides de vue (view helpers), et que le template est la vue.

Je trouve ce système très bien foutu, et il montre une très grande flexibilité.

Mais attention (toujours un « mais »), cette architecture ouvre plus encore la porte vers les mauvaises pratiques. C’est à dire l’utilisation d’une couche pour laquelle elle n’est pas prévue.

Si vous vous demandez encore quel est précisément le rôle de chaque couche dans le paradigme MVC, ça sera pire avec Magento. Et c’est précisément le problème ici, beaucoup de développeurs utiliseront malheureusement le block comme un contrôleur d’actions, et un tel découplage laisse présager un véritable foutoir dans certains projets.

Création de module dans Magento

Je n’ai pas grand chose à dire sur cette partie. Une fois le système de block et la couche « Modèle » bien assimilés, la création de module ne devrait pas vous poser de problèmes. Si ce n’est quelques spécificités comme par exemple si vous souhaitez inclure une galerie d’images administrable (bon courage avec ça :p).

L’utilisation du modèle EAV n’est pas obligatoire, vous pouvez très bien définir des entités et les implémenter de manière classique.

La seule contrainte est l’utilisation abondante de XML pour configurer le module, et l’absence de documentation précise vous promet quelques heures de recherche.

L’ajout d’un module dans l’administration du site est un peu délicat au début (notamment les formulaires), mais une fois le baptême du feu passé, vous irez beaucoup plus vite. Magento propose des widgets permettant de créer « facilement » des grilles pour vos collections de données et des formulaires pré-formatés pour la modification de votre modèle.

Dans Magento tout doit être fait manuellement, en programmation. Si vous vous attendiez à créer simplement votre boutique à l’aide de la souris et d’une interface type CMS, c’est raté, vous devrez implémenter vous même vos modèles, contrôleurs, blocks et templates, comme vous le feriez avec Zend Framework (mais en plus complexe :p).

CMS

Ça va être très court. Le CMS de Magento laisse vraiment à désirer. Si vous comptiez inclure des pages de contenu avec une mise en page un peu recherchée et qui seraient administrables par le CMS, vous pouvez lâcher tout de suite l’affaire.

Ce module est plus qu’insuffisant et vous fera parfois abandonner Magento au profit d’un véritable CMS quitte à se contenter d’un module e-commerce très limité.

Le CMS vous permet de créer des pages ou des blocks statiques. Le petit plus est qu’il permet d’inclure des variables ou des blocks dynamiques au sein de votre page grâce à des « insert tags ».

Pour le reste, le CMS vous permet de modifier le layout XML de la page directement dans l’admin plutôt que dans un fichier. Il y a peu d’intérêt, sauf si vous formez votre client et qu’il se sent capable de modifier le layout, mais je dis attention !

Les petits plus

Magento regorge de petites options pratiques, surtout pour les développeurs. Bien sûr c’est relatif, c’est pratique dans un contexte où tout est complexe

Vous pouvez activer par exemple un mode de traduction qui vous permet de traduire les clés CSV directement dans le site. Ou encore activer un débuggueur, configurer des notifications pour vos tâches CRON, réunir tous les fichiers javascript et CSS en un seul fichier, etc etc.

Je citerai aussi Magento Connect et son écosystème de modules qui est vraiment très appréciable. Il s’agit en fait d’un GUI (interface) qui vous permet de déclencher des installations et des mises à jour façon PEAR, tout ça avec la souris. Les versions des modules sont bien gérées, mais attention tout de même à ne pas installer n’importe quoi.

Conclusion

Vous l’aurez compris, l’apprentissage de Magento demande une certaine maîtrise du développement et beaucoup d’investissement.

Cet article est un premier retour sur l’architecture du projet et je ne prétend pas maîtriser l’outil au point que mes arguments soient considérés comme une vérité générale. Si vous n’êtes pas d’accord avec certaines idées, n’hésitez pas à vous exprimer.

Je ne peux aussi pas faire le tour de toutes les possibilités dans un seul article. Je n’ai par exemple pas parlé du SEO ou de la gestion des droits, et j’en passe.

Bien que j’admire certaines parties du système, j’émets de grosses réserves sur les performances avec un catalogue produits conséquent (> à 5000 produits).

Je trouve aussi dommage que Varien n’ait pas fait plus d’efforts sur la documentation et ne propose pas de mieux guider les développeurs dans le choix de cette solution. C’est un véritable frein et beaucoup de développeurs abandonneront en cours de route.

Néanmoins, Magento reste pour le moment et pour moi, la Rolls des solutions e-commerce libres sur le marché.

Pour ceux qui ne sont pas au courant, je vous invite à lire les billets suivants :

• Utiliser un moteur de template avec PHP, pourquoi ?
• Utiliser Twig avec Zend Framework 1.1x

J’ai apporté quelques améliorations, notamment grâce aux retours de Mickael Perraud que je remercie au passage.

La librairie supporte maintenant plusieurs moteurs de templates au sein d’une même application. Ceci implique quelques modifications dans la configuration :

Pour des raisons pratiques (je suppose pour faciliter la migration vers Twig), Mickael a ajouté une aide d’action (et les tests unitaires qui vont avec, merci :p) qui permet de définir le moteur à utiliser selon l’action de contrôleur, grâce à une simple annotation.

Exemple :

J’ai également ajouté une nouvelle extension : « trans », qui s’utilise comme ceci :

Les modifications ont été fusionnées avec la branche « master » sur github : http://github.com/benjamindulau/Ano_ZFTwig

Je vous invite aussi à consulter le README qui a été mis à jour.

Toute cette intégration peut sembler superflue avec l’arrivée des nouvelles versions majeures des frameworks Zend et Symfony, mais beaucoup de projets démarrent encore avec ZF 1.x.

Bon twig !

Comme je l’expliquais, avec les mauvaises expériences, je reviens sur mes positions concernant les moteurs de templates. Mais ce n’est pas la seule raison, si mon intérêt se porte de nouveaux sur un tel système c’est aussi grâce à l’arrivée de nouveaux moteurs de templates complets, flexibles, et surtout très performants.

Mon attention s’est récemment portée vers Twig, un moteur de templates proposé par Fabien Potencier (créateur de symfony). Fabien a fait revivre le moteur initialement créé par Armin Ronacher (pour une plateforme de blogs), a amélioré le code, et propose au moment où j’écris ces lignes, une version 0.9.9, plus qu’un pas vers une version « officiellement » stable donc.

En jouant avec le moteur, j’ai rapidement été convaincu, et je me suis vite mis à chercher si une intégration avec Zend Framework existait. J’ai trouvé quelques propositions d’intégration, certaines abandonnées, d’autres incomplètes, ou encore incompatibles avec la version actuelle de Twig.

Après quelques bidouillages, j’ai décidé de créer ma propre intégration du moteur, que je ferai évoluer en fonction des besoins.

Comment fonctionne Twig ?

Pour ce qui est des fonctionnalités du moteur, je vous laisse lire la documentation sur le site officiel.

Ce qui nous intéresse plus ici, c’est la flexibilité de la bête. Et vous ne serez pas déçus.

Après avoir passé quelques heures à lire le code source et à faire quelques tests pour comprendre le fonctionnement du parser, j’avoue que je suis surpris par la facilité d’appréhension du système. Tout est extensible, il est assez simple d’étendre le coeur du moteur et simple aussi de créer de nouveaux tags. Je ne suis pas certain d’avoir utilisé toutes les possibilités offertes pour mon intégration dans Zend Framework, mais je ne manquerai pas de faire évoluer les choses au fur et à mesure de mes découvertes.

Twig utilise un objet appelé environment qui est utilisé pour stocker la configuration, les extensions et pour charger les templates. Dans la plupart des cas, un objet environment est créé et est ensuite utilisé pour rendre tous les templates de l’application.

Pour charger les templates, un objet loader est fourni à l’environnement, il est responsable de charger les templates depuis une resource, par exemple une chaine ou un fichier.

Une extension est un ensemble de fonctionnalités ajoutées à Twig. Dans Twig, tout est extension, même le coeur du moteur. Le moteur est livré avec plusieurs extensions permettant de proposer un panel de fonctionnalités très confortable.

Pour ce qui est de la création de nouveaux tags, le fonctionnement de Twig est assez simple, il faut au minimum :

• une extension qui sera pluggée à Twig et qui regroupe un ou plusieurs parsers
• un ou plusieurs parser (soit un générique, soit un pour chaque tag)
• un ou plusieurs noeuds, objets qui vont compiler le code en PHP.

Pour parser la syntaxe d’un tag, Twig utilise une « grammaire » particulière pour chaque type d’expression (arguments de type constante, tableau, variable, etc.). Chaque grammaire est associée à un parser. De cette manière, Twig est capable d’analyser automatiquement le contenu d’un tag et d’en extraire différentes expressions.

Voici un exemple de tag :

Et voici la grammaire de ce tag :

Un tag est considéré comme un noeud contenant un ensemble d’expressions (chacune associée à une grammaire) pouvant elles-mêmes être des noeuds. Une fois que le parser a interprété un tag, il invoque un objet node qui se charge de compiler (via un objet compiler) chaque expression du noeud en PHP. Pour pouvoir être compilée, chaque classe d’expression possède une méthode compile qui se charge de retourner la représentation PHP de l’expression.

Par exemple, l’expression :

Dont la grammaire est :

Sera compilée en :

Il est donc possible d’ajouter de nouvelles « grammaires » selon les besoins et de créer les parsers et expressions associés.

Je ne vais pas m’étaler plus sur le fonctionnement interne du moteur. D’une part parce que je n’arriverai pas à couvrir toutes les possibilités dans un article et ensuite parce que c’est bien plus compliqué à expliquer qu’à utiliser. La meilleure façon pour vous de comprendre le fonctionnement est de parcourir les sources, de vous amusez avec le moteur et de tenter de créer vos propres extensions.

Intégration avec Zend Framework

Il existe deux points difficiles pour l’intégration avec ZF :

• conserver le fonctionnement de Zend_Layout
• Proposer une syntaxe pour invoquer les aides d’actions.

Il n’y a pas de magie, certaines aides d’actions devront être spécifiquement implémentées dans une extension pour pouvoir fonctionner. Pour cette première intégration, j’ai créé des tags pour certaines aides d’actions indispensables natives au framework. A vous de compléter mon travail en fonction de vos besoins.

Utilisation de Zend_Layout ou non ?

C’est une question de choix, et surtout de goûts.

Twig propose nativement un système d’héritage des templates. Vous pouvez vous passer complètement de Zend_Layout en utilisant cette fonctionnalité. La différence est que dans Twig, les templates enfants sont rendus après les templates parents. Certaines choses qui vous semblaient peut-être naturelles ne le seront plus.

Exemples

Sans Zend Layout et avec l’héritage de templates :

views/layouts/layout.twig

views/index/twig-zf.twig

Avec Zend Layout :

Le même exemple en utilisant Zend Layout, sachant que la vue est rendue avant le layout, donc impossible d’utiliser les block. L’utilisation de Zend Layout implique aussi l’utilisation de certains tags spécifiques que vous retrouverez dans le package Ano_ZFTwig.

views/layouts/layout.twig

views/index/twig-zf.twig

Vous remarquez ici les options prepend pour l’ajout de JS et de CSS, comme la vue est rendue avant, les scripts ajoutés dans le layout doivent aller au dessus de la pile, exactement comme si vous utilisiez le moteur de templates par défaut de Zend Framework.

Vous voyez aussi que les tags javascripts & co n’ont pas besoin d’être dans un block, comme le layout est rendu après la vue, les stacks seront prêts au moment de l’affichage.

Installation et configuration

Pour installer la librairie :

• téléchargez les sources : http://github.com/benjamindulau/Ano_ZFTwig
• placez le package Ano dans le dossier library de votre projet
• ajoutez les lignes suivantes dans votre application.ini :

Pour configurer et activer Twig ça se passe dans application.ini :

Pour les options de Twig je vous laisse lire la doc officielle pour les développeurs.

Il faut penser à bien ajouter tous les chemins vers les scripts de vues, y compris les chemins vers les layouts si vous n’utilisez pas Zend_Layout.

Si vous souhaitez utiliser Zend_Layout, il suffit d’ajouter sa configuration :

Et c’est tout

Utilisation

Vous n’avez rien à changer dans vos contrôleurs pour utiliser Twig, vous continuez à développer comme d’habitude, le viewrenderer se chargera automatiquement de rendre les vues avec le moteur de Twig.

Pour les fonctionnalités courantes du moteur je vous redirige encore vers la doc officielle (pour les designers cette fois-ci).

Les tags additionnels inclus dans le package Ano_ZFTwig :

(pas de coloration syntaxique, désolé :p)

Conclusion sur un exemple avancé

Avant de vous laisser, je vous propose de voir la version Twig de l’exemple que j’ai donné dans l’article : Utiliser un moteur de template avec PHP, pourquoi ?

Souvenez-vous, notre vue qui affiche une vidéo utilisateur :

La version Twig :

Attention

Dans cet exemple j’utilise certaines expressions (is allowed par ex.) que vous ne retrouverez pas dans le package Ano_ZFTwig. C’est une indication pour vous donner une idée de la syntaxe équivalente avec Twig. Ces fonctionnalités sont spécifiques, à vous de les implémenter.

Je suis conscient qu’il reste encore un peu de travail pour une intégration complète dans ZF, mais je vous laisse le soin d’ajouter vos propres briques à l’édifice, je ne doute pas que vous allez jouer avec les sources et les adapter selon vos besoins.

Au plaisir !

Premièrement, PHP a évolué, et même si son inventeur, Rasmus Lerdorf, l’a crée dans le but de dynamiser plus facilement son code HTML, le langage a depuis beaucoup changé. Il s’est professionnalisé, son modèle objet est devenu robuste, et avec la démocratisation des bonnes pratiques de développement web et notamment la séparation « of concerns » (qui peut me donner la bonne traduction ?), il est devenu bien plus qu’un simple moteur de rendu.

Ensuite, avec le recul et après avoir expérimenté pas mal de projets MVC dans lesquels la couche présentation (vues) est construite avec PHP, la question d’utiliser un moteur de templates revient naturellement.

Ce thème est sujet à débats, et vous ne serez certainement pas tous d’accord avec mes arguments, tout comme moi auparavant. Je vais tenter de vous faire comprendre pourquoi je suis revenu sur mes positions.

La preuve par l’exemple

Pour vous aider à comprendre ce qui me fait changer d’avis, jetons un coup d’oeil au script de vue suivant :

Vous l’aurez compris, il s’agit d’une vue qui affiche une vidéo d’un utilisateur, avec ses commentaires. L’exemple est simplifié, pas de traductions, pas d’avatars pour les auteurs, pas de partials, etc. Et ici je ne parle même pas du layout.

Osez me dire que c’est facile à maintenir ! :p

Des $this et des < ?php echo … ?>, mangez-en…

Sur un de nos projets, nous nous sommes finalement perdus et c’est devenu très difficile de maintenir la couche présentation du site.

De plus, lors de l’intégration, nous sommes souvent tentés de faire du traitement dans les vues, chose à éviter, la vue affiche les données et c’est tout, il ne faut pas mélanger les responsabilités de chaque couche de l’application. Un moteur de templates aide à résoudre ce problème.

Les avantages d’un moteur de templates

Les avantages apportés par un moteur de templates tel que Twig sont simples :

Une syntaxe propre et condensée dédiée au design (réutisabilité)

Les intégrateurs peuvent se concentrer sur un langage et une syntaxe qui à priori ne changeront pas, contrairement à PHP qui évolue (dépréciation de fonctions par exemple).

Que dire de plus sur ce point, c’est aussi une histoire de goût.

Un code HTML beaucoup plus lisible

Ceci est indéniable, le code HTML devient beaucoup plus lisible, si le moteur de templates est maitrisé il y aura moins de chance de se perdre dans le code.

Ce point est facile à défendre mathématiquement. Pour afficher une variable de manière sécurisée avec PHP et Zend Framework, il faut compter au moins 36 caractères, sans compter le nom de la variable en elle-même et en supposant que nous n’accédons pas une propriété d’un objet ou une valeur de tableau.

Avec un moteur tel que Twig :

Quelque chose à ajouter ?

Interdir du traitement dans les vues

Ce point est crucial et reste pour moi un des avantages les plus importants. Impossible (en théorie) de s’enfoncer dans un code alambiqué dans lequel nous finirons par nous perdre.

Sécurité

Certains me diront que c’est au développeur de faire attention et que celui qui oublie d’échapper une variable avant de l’afficher mériterait une sanction pire que la mort. Je suis plus ou moins d’accord (mais je suis ok sur la sanction ).

C’est très facile dans la jungle PHP d’une vue d’oublier un « escape » ou pire, sans framework, le très verbeux « htmlspecialchars(….) ». Ça arrive au meilleur d’entre nous.

Dans la plupart des moteurs de templates il est possible d’activer un échappement automatique des variables et une intervention n’est nécessaire que si nous ne souhaitons pas échapper une expression, ce qui est quand même relativement rare. Fonctionner dans ce sens est donc logique, et nous n’avons plus besoin de nous soucier de ça. Sans parler de la lisibilité qui est largement accrue.

Je sais que dans le cas de Javascript il faut faire très attention à l’échappement des tags, mais quand bien même, c’est toujours mieux que de devoir systématiquement tout échapper à la main.

Dans un monde parfait, j’ajouterai à cette liste l’interopérabilité entre langages/framework, mais ça insinuerait une syntaxe universelle et un portage du moteur vers les différents langages, c’est toujours bon de rêver

Les inconvénients d’un moteur de templates

Bien entendu, rien ne vient sans son lot de problèmes

Voici les inconvénients majeurs d’un moteur de templates :

Coloration syntaxique dans les IDE

A moins que le moteur de templates soit suffisamment réputé pour bénéficier d’un plugin pour votre IDE, il ne faudra pas espérer avoir une coloration syntaxique (à moins de le faire soi-même), ce qui peut être frustrant.

Chute de performances. Pour certains moteurs c’est même épouvantable.

Les performances de l’application sont inévitablement touchées. Il faut parser et compiler le template en PHP, ce qui demande un certain temps. Parfois, certains moteurs pourtant assez pauvres en fonctionnalités sont une véritable catastrophe en terme de performances. Il faut donc faire très attention à ça au moment de choisir son moteur de templates.

Pour pallier à ce problème, des moteurs comme Twig ou Smarty permettent de mettre en cache le résultat de la compilation PHP des templates. Mais pour Smarty par exemple, ce n’est pas suffisant, le moteur étant devenu une véritable usine à gaz, les performances sont assez médiocres.

Un manque de fonctionnalités frustrant et dangereux

Parfois, les moteurs ne proposent pas de solutions pour obtenir ce qu’on veut, ce qui poussent à utiliser PHP quand même par des feintes pas très jolies jolies (qui se reconnait ? :p).

Difficile de parser/débugger un template

Autre point qui peut en rebuter certains. Il devient plus difficile de débugger un template. Le moteur doit soit intégrer sont propre débuggueur, soit il faut aller débugger manuellement le résultat des compilations dans le cache, je n’en dis pas plus, vous comprendrez la lourdeur de la manipulation.

Il devient également difficile de parser les fichiers. Dans le cas d’une internationalisation avec gettext par exemple. Mais ce problème n’est pas sans solution.

Casse la structure (x)HTML

Dans certains cas, les moteurs de templates cassent la structure du (x)HTML. Un exemple parfait :

Alors qu’en (x)HTML le W3C recommande que rien ne doit être présent entre les tags tbody et tr.

Je dirais tout simplement que c’est un faux problème étant donné qu’il existe aussi si on utilise PHP comme moteur de rendu.

Difficile d’insérer du Javascript

Conclusion

En étant pragmatique :

• avantages : 4
• inconvénients : 6

6 > 4, il ne faut donc pas utiliser un moteur de templates.

Non, je n’oserai pas. D’une part parce que je ne suis pas certain d’avoir cité tous les avantages et les inconvénients. D’autre part parce qu’il y a les puristes, les grand défenseurs de PHP ou de Smarty, et j’en passe.

Sachez seulement que je me suis finalement laissé séduire. Les raisons sont finalement simples, une maintenance du code beaucoup plus facile et l’arrivée de nouveaux moteurs de templates qui offrent un excellent rapport fonctionnalités/performances.

Le dernier en date qui m’a convaincu : Twig.

Je vous propose d’ailleurs une intégration de Twig avec Zend Framework 1.1x dans l’article : Utiliser Twig avec Zend Framework 1.1x

Utiliser PHP comme moteur de template est une bonne chose mais implique une légère complexité du code dans les vues. Du $this, du escape, des array et j’en passe, certains morceaux de code deviennent très pénibles à lire et polluent le html.

Aujourd’hui nous nous intéressons à l’aide de vue url, dont la syntaxe est :

Ce qui intégré donne :

Je pense que ça se passe de commentaires, tout ça devient très vite un véritable foutoir.

La syntaxe avec les routes et les paramètres par défaut peut être raccourcie :

Mais ce n’est pas encore idéal.

Utiliser un pattern pour composer les URLs

Je vous propose une aide de vue qui va générer les URLs en fonction d’un pattern inspiré de l’aide de symfony premier du nom et qui permet de transformer les exemples ci-dessus en :

Pour ce qui est du code, j’avoue ne pas avoir regardé la source dans symfony 1.x qui est peut-être meilleure, mais voilà le code :

Ce fichier est à placer dans votre dossier « library » (ou autre nom), et vous devez ajouter le namespace dans le fichier de config. application.ini :

Rien ne vous empêche de l’améliorer si nécessaire (même dans les commentaires :p).

Utilisation

URLs « standards »

Comme vous pouvez le voir dans le code, j’ai décidé de 3 cas d’utilisation :

/:module/:controller/:action/*

/:controller/:action/*

Le module par défaut sera utilisé.

/:controller/*

Le module par défaut et l’action index seront utilisés.

Avec une route

Imaginons la route suivante :

Pour obtenir la route par défaut, tout simplement :

Avec des paramètres :

Il est possible aussi (heureusement) de pouvoir redéfinir les module/action/contrôleur :

Le modèle de conception MVC impose une certaine granularité des différentes « actions » assurées par l’application. Chaque contrôleur possèdent un certain nombre d’actions possédant chacune un rôle bien défini (le plus souvent un cas d’utilisation).

Plus le nombre d’actions se multiplie, plus la redondance de code devient inévitable.

Le premier réflexe pour un bon développeur orienté objets qui se respecte, sera de créer des super-classes de contrôleur et d’user de l’héritage pour factoriser le code. Mais l’héritage ne répond pas à tous les problèmes.

Ce n’est parfois pas très flexible dans le sens où chaque contrôleur n’a pas forcément besoin des mêmes fonctionnalités, alors que tous possèdent un pan commun. Dans ce cas là, vous vous retrouvez à créer plusieurs super-classes pour chaque groupe de fonctionnalités mais dans lesquelles vous répétez finalement du code commun à chaque super-classe.

Que faire alors ? Créer encore une super-classe et se retrouver avec un nivelage d’héritage important qui complexifie la compréhension du code et devient difficile à maintenir ? Non

Les aides d’action ou helpers, mangez-en !

Les aides d’action répondent exactement à cette problématique. Ce sont des plugins (ne pas confondre avec les plugins de contrôleurs !) qui permettent d’ajouter des fonctionnalités aux contrôleurs d’actions sans avoir à étendre de classe. Ils peuvent soit être injectés automatiquement, soit à la demande du développeur, dixit la documentation du ZF : Aides d’actions (Helper).

Mais lorsqu’on débute dans l’utilisation d’un framework tel que Zend Framework, l’utilisation de tels mécanismes n’est pas innée, loin de là. Et pourtant, le ZF regorge de fonctionnalités variées qui facilitent le développement et l’organisation du code, ce serait dommage de s’en priver. Je vous encourage donc à vous forcer à utiliser les aides d’actions jusqu’à ce que ça devienne un réflexe.

Automatiser l’exécution d’un helper (hooks)

Les aides d’actions peuvent soit être invoquées à la demande, soit intervenir automatiquement à des moments clés du processus de dispatch des contrôleurs d’action.

Pour ça, il existe trois méthodes (hooks) :

• init() : invoquée automatiquement au moment de l’initialisation du contrôleur d’actions.
• preDispatch() : invoquée juste avant la routine preDispatch() du contrôleur d’actions.
• postDispath() : invoquée juste après le postDispatch() du contrôleur.

Ces trois méthodes sont invoquées automatiquement pour chaque aide d’action enregistrée, il est donc important de bien choisir à quel moment un helper doit intervenir dans le processus.

Exemple (simple): Restreindre les actions à un verbe HTTP

Le champ d’application des aides d’action est très varié, il peut s’agir aussi bien d’une fonctionnalité basique ne nécessitant que quelques lignes de code que de l’implémentation d’une logique complexe. Je ne vais donc pas m’enfoncer dans un exemple trop compliqué et plutôt vous montrer un cas typique d’utilisation qui peut vous faciliter la vie, à vous et votre imagination de faire le reste

Qui n’a jamais utilisé cette ligne de code dans une action de contrôleur ?

Dans de gros projets, c’est typiquement un morceau de code qui sera répété des dizaines de fois, parfois plusieurs fois dans le même contrôleur. Pourquoi ne pas utiliser une aide d’action similaire au context switcher qui permettrait de déclarer un simple attribut dans le contrôleur, exemple :

Voilà le code du helper, dans lequel vous remarquerez, que fainéant comme je suis, j’ai copié/collé pas mal de code d’un helper déjà existant dans le ZF

Ici j’utilise le « hook » preDispatch() qui sera systématiquement invoqué pour chaque contrôleur d’action juste avant de dispatcher l’action. Attention de bien enregistrer l’aide dans le broker d’actions dans ce cas là.

Dans le bootstrap (par exemple) :

Avec ça, vous n’avez plus qu’à déclarer votre propriété $httpContexts dans le contrôleur et le tour est joué.

C’est un exemple tout bête, mais qui donne une bonne idée de l’utilité du mécanisme.

Pattern Strategy

Les aides d’actions dans le Zend Framework implémentent le pattern Strategy sur le helper broker (gestionnaire d’aides d’action) qui permet ici d’invoquer directement une aide d’action comme s’il s’agissait d’une méthode du broker.

Il s’agit en fait d’utiliser la méthode clé direct() comme un proxy vers une méthode du helper. Ce mécanisme est utile dans le cas des aides d’action invoquées à la demande et permet de simplifier le code. Exemple avec l’aide d’action « redirector » inclue dans le ZF :

Si nous jettons un coup d’oeil à la source du helper :

D’autres exemples

Voici quelques exemples courant d’aides d’action :

• Automatiser le contrôle des ACL – Julien Pauli
• Historique de navigation (session)
• Vérifier qu’un utilisateur est authentifié
• j’ai rien d’autre qui me vient, mais tout ce vous sera utile et qui justifie l’utilisation d’un helper.

Et bien entendu tous les helpers inclus dans le framework que les développeurs oublient souvent d’utiliser

Limitations & Conclusion

Comme toujours, un composant ne vient pas sans son lot de critiques que ce soit dans le design, l’implémentation du concept ou son utilisation.

Pour ma part, je trouve l’outil très utile et je serais idiot de m’en passer pour des considérations purement philosophiques. Le seul point, et pas des moindre, qui me limite dans son utilisation, sera la difficulté pour y injecter quoi que ce soit. Le chargement étant assuré par un gestionnaire (le broker) utilisé de manière statique, il est très difficile de pratiquer l’injection de dépendances dans les helpers. Le ZF n’est pas prévu pour fonctionner avec un conteneur de dépendances, ou du moins n’est pas toujours adapté pour ça.

Néanmoins, les aides d’actions restent utiles tant qu’elles ne nécessitent pas de dépendances. Je pense que les développeurs du ZF sont conscients de cette problématique et nous proposerons une implémentation plus flexible dans la version 2 du framework.