PHP est, depuis plusieurs années maintenant, un des langages Web les plus employés, tant sur le marché des particuliers que sur celui des entreprises. Malgré plusieurs tentatives de mutualisation de code (PEAR [1], etc.), aucune initiative n’a su s’imposer de manière durable comme LE framework incontournable pour la création rapide d’applications extensibles, fiables et performantes. Les années 2005 et 2006 ont vu fleurir nombre de frameworks MVC [2], souvent inspirés de la mode lancée par Ruby On Rails (Ruby) ou encore Django (Python). Les caractéristiques communes à ces nouveaux outils répondent à de nouveaux enjeux : respect de MVC, scaffolding [3], prise en compte de problématiques de déploiement, aides à la mise en œuvre d’Ajax, etc.

Attentive à l’apparition de cette nouvelle génération d’outils PHP, Clever Age a peu à peu développé une expertise dans leur utilisation au service des projets client. Cependant, si les commentaires enthousiastes se succèdent au sujet de Symfony, Cake PHP, ou du Zend Framework, le développement de projets Web autour d’un framework demeure encore assez rare. Plusieurs raisons peuvent expliquer cette frilosité du marché face à ces nouveaux outils, qui pourtant accélèrent grandement le temps de développement des projets Web et leur permettent d’atteindre de nouveaux standards de qualité et des objectifs plus élevés qu’auparavant.

Tout d’abord, la mode des frameworks et l’intérêt pour la capitalisation des efforts de développement sont encore assez récents. Auparavant, développer from scratch une plateforme Web autour du couple PHP/MySQL nécessitait un effort important pour l’assemblage de briques logicielles disparates, et la qualité des projets Web issus de développements spécifiques s’en ressentait bien souvent. Peu à peu, c’est donc l’adaptation de CMS [4] aux besoins des projets qui a pris le pas sur les développements spécifiques. Or, cette stratégie de l’extension du CMS est en train de trouver sa principale limitation : la difficulté à intégrer une logique métier dans des outils pas forcément prévus pour cela à la base.

Deuxième point intéressant, la sphère logicielle PHP peine encore à dégager une solution unique, facilement identifiable, et reconnue, ce que la langage Ruby a su faire avec Ruby on Rails et, dans une moindre mesure, Python avec Django. Symfony est pour l’heure le framework PHP qui nous semble le plus abouti, surtout avec les avancées prévues pour la version 1.0 du projet français. Ceci dit, nous trouvons intéressant de rester critiques face à l’engouement généralisé que suscite Symfony, aussi nous avons établi une liste qui reprend nos principales interrogations et doutes sur les choix effectués :

Persistance

Il existe de (trop) nombreuses solutions de persistance de base de données pour PHP. Les développeurs de Symfony ont fait le choix d’utiliser Propel au sein du framework et l’ont remarquablement bien intégré :

• générateur d’interfaces d’administration
• gestion automatique de la notion d’internationalisation
• génération des classes de persistance à partir de la description XML du modèle
• comptage des requêtes effectuées, timing, etc

Cependant, Propel souffre de quelques problèmes :

• les performances sont loin d’être exceptionnelles (c’est le point le plus important)
• les relation n:m ne sont pas gérées nativement

Face à ces problèmes, les développeurs de Symfony et la communauté ont décidé de permettre l’utilisation d’autres moteurs de persistance : Propel a été retiré du cœur de Symfony et mis à disposition sous la forme d’une extension et le travail d’intégration de Doctrine à commencé.

Doctrine présente des avantages certains :

• d’excellentes performances (notamment grâce à son utilisation de l’extension PDO comme couche d’abstraction)
• des fonctionnalités avancées (Doctrine propose nativement des fonctionnalités extrêmement intéressantes dont ne dispose pas Propel : Validators, Event Listeners, Locking, etc)
• une documentation formelle

Pourtant l’utilisation de Doctrine dans le cadre de projets professionels nous semble pour le moment prématurée :

• à court terme : de l’aveu même de son développeur, le plugin intégrant Doctrine à Symfony est encore immature. Mais au vu de la très forte activité autour de ce plugin, cette situation ne devrait pas durer.
• à long terme : Quid de la pérennité du projet Doctrine, dont le seul développeur est un étudiant finlandais ? On peut espérer que l’intégration à Symfony aidera au développement d’une communauté autour de la solution d’ORM [5], mais rien n’est moins sûr, d’autant plus qu’à l’heure actuelle aucune infrastructure communautaire (hormis un forum) n’est disponible pour le projet : pas de contrôle des sources, pas de gestionnaire de bugs, impossibilité de créer de la documentation.

Quelle solution choisir [6] ? En attendant la maturation de Doctrine, il reste plus prudent de continuer à utiliser Propel, dont la version 1.3, basée sur PDO devrait résoudre le problème des performances.

Internationalisation

De tous les frameworks d’application web que nous avons pu tester, Symfony est celui qui offre le support de l’internationalisation et de la localisation le plus abouti. Quelques problèmes subsistent cependant :

• L’extraction automatique des chaînes à traduire reste assez complexe à mettre en œuvre
• La documentation de l’utilisation des différents backends de traduction disponibles (Gettext, base de données, XLIFF) est encore trop légère

Un dernier effort sur ce point [7] fera de Symfony le framework de référence pour les développements mettant en jeu des problématiques d’internationalisation.

Performances

• Dans les versions de développement de Symfony (0.6, 0.8), les peformances du framework étaient sujettes à questionnement. Depuis, un gros travail sur le sujet a été effectué pour la version 1.0, et devrait porter ses fruits en accélérerant grandement le framework, qui n’aura alors plus à rougir face à ses concurrents dans d’autres langages Web.

• Le système de cache de Symfony est très performant et a été pensé d’une manière intéressante. Il est hiérarchisé en plusieurs niveaux, dissociant modes de développement et de production, applications, modules, paramètres passés aux actions/composants, etc. Dans le cas d’actions appelées avec une très large collection de paramètres différents, il peut donc y avoir plusieurs milliers de sous-dossiers au même niveau de l’arborescence, et le cache peut alors être assez lent à vider.

Documentation

• La documentation de Symfony, exemplaire en tous points pour les anglophones, reste un facteur limitant pour une adoption internationale et homogène du framework. Certaines initiatives isolées commencent à traduire les pages du wiki, mais ces efforts restent encore trop disparates pour vraiment favoriser l’adoption massive de Symfony. Des appels à contribution pour la traduction de la documentation, mieux encadrés, donneraient à Symfony une inestimable longueur d’avance sur ses concurrents.

• La très grande qualité de la documentation disponible sur le framework n’empêche pas certaines informations à nos yeux essentielles d’en être totalement écartées, comme les spécificités de la gestion du filtrage des données par exemple.

Outillage

• Pour l’instant, la configuration fine du framework et des applications construites autour de Symfony se fait par le biais de fichiers YAML [8], qui souffre de certaines limitations (certains caractères sont interdits, pas de retour à la ligne, etc.). Il serait assez sympathique de pouvoir choisir le format des fichiers de configuration, au moins avec une alternative XML, dont l’avantage principal serait de profiter de tout l’écosystème XML existant. Il serait ainsi possible, par exemple, de paramétrer finement une instance de Symfony par le biais d’interfaces graphiques ! Certes, Symfony permet dès maintenant de coder ses propres compilateurs de configuration, mais il est dommage qu’une configuration XML ne soit pas supportée nativement par le framework.

• Les tâches Symfony manquent de formalisme : il serait bon de pouvoir spécifier plus clairement quels arguments sont acceptés et de disposer d’une documentation d’utilisation générée à partir de cette spécification.

• L’utilité du "Control Panel" - alternative à la ligne de commande pour les tâches courantes d’administration - n’a pas été prouvée. Sa finition fait-elle partie des objectifs de Symfony 1.0 ?

• Curieusement, le générateur d’interface d’administration (ou "admin-generator") de Symfony ne propose pas encore d’éditeur de date/heure en mode texte. Seul un éditeur riche, sous forme de calendrier, est disponible, mais son intégration dans Symfony ne permet pas de modifier simplement les heures (alors que le projet de calendrier utilisé, The DHTML/Javascript Calendar, le permet tout à fait).

• Si on veut être tatillon, on pourrait râler au sujet de l’internationalisation au sein des actions Symfony, qui nécessite à chaque fois de faire un appel à $this->getContext()->getI18n()->__('Chaine à traduire'). Un appel statique du style sfI18N::__('Chaine à traduire') ou, dans le pire des cas, $this->getI18n()->__('Chaine à traduire'), serait sans doute moins pesant à employer.

• Symfony intègre nativement les tests unitaires, et est lui-même intensivement testé : c’est un très bon point. Mais alors qu’il existe déjà des outils reconnus dédiés à cette tâche, en quoi était-il nécessaire d’en développer un nouveau ? Ce re-développement détone, pour un projet qui prône la réutilisation de code.

Clairement, ce ne sont pas là des points qui remettent en cause notre intérêt pour le projet Symfony, récemment adopté par Yahoo ! pour la refonte de Yahoo ! Bookmarks. Notre objectif n’est pas de faire la critique absolue de Symfony, mais bien plutôt de mettre le doigt "là où ça fait mal", afin de contribuer à l’amélioration de ce formidable outil qui arrive très bientôt en 1.0 ! Et vérifier un vieil adage, par la même occasion : "qui aime bien châtie bien" !