Derrière ce titre que Franz Schubert ne renierait pas se cachent nos interrogations au sujet de l’excellent framework Symfony qui, à peine un an après son lancement, s’impose peu à peu sur le devant de la scène PHP.
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[PEAR n’est pas un framework en soi; il serait plus juste de parler de [framework technique.]], 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 [MVC ou [Modèle Vue Contrôleur.]], 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[Le scaffolding (“échafaudage”, en français) est la structure de base permettant d’effectuer des opérations de type CRUD (Create, Retrieve, Update et Delete) sur une table de données. Pour plus d’informations, voir le [chapitre de la documentation de Symfony consacré au scaffolding.]], 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[Content Management System, ou Système de Gestion de Contenus]] 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[[cf. [http://en.wikipedia.org/wiki/Object-relational_mapping->http://en.wikipedia.org/wiki/Object-relational_mapping].]], 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[[Une discussion sur ce sujet, avec les développeurs de Symfony et celui du plugin Doctrine a eu lieu récemment : [http://groups.google.com/group/symfony-fr/browse_thread/thread/ac3c0137f1942a99/->http://groups.google.com/group/symfony-fr/browse_thread/thread/ac3c0137f1942a99/].]] ? 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[[Un travail communautaire a déjà commencé : [http://www.symfony-project.com/trac/wiki/HowToGenerateI18NFiles->http://www.symfony-project.com/trac/wiki/HowToGenerateI18NFiles].]] 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[« YAML Ain’t Markup Language », ou YAML, est un format de représentation des données très facilement utilisable par les machines. Les fichiers YAML portent généralement l’extension *.yml. Plus d’informations sur le [site officiel du format YAML.]], 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 stylesfI18N ::__('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 » !
francois
3 novembre 2006
Merci pour cette analyse intéressante. A la différence de Franz Shubert, qui est mort à 31 ans, symfony n’est encore qu’un prématuré et sa version 1.0 devrait combler pas mal des lacunes listées ici.
Quant à la documentation en français et à une démarche plus concertée, je propose de la lancer ici et maintenant. Messieurs de CleverAge, plutôt que de prendre des pauses café, traduisez la doc de symfony!
Blague à part, la documentation est un peu en sommeil pour l’instant, mais pour une bonne raison : nous travaillons à la rédaction du livre symfony, dont la traduction (qui représentera un intérêt financier évident pour des éditeurs français) sera bien plus facile.
Au plaisir de vous rencontrer d’ici peu!
Laurentj
3 novembre 2006
Il y a aussi le framework Jelix ;-) il ne prétend pas tout résoudre, il lui manque encore des trucs, mais son objectif premier est la performance à tous les niveaux et il semble combler quelques unes des lacunes que vous citez. D’ailleurs il a été choisi par une grosse plateforme de blog pour sa prochaine version (et les perfs sont au rendez vous semble-t-il). http://jelix.org
À noter que Doctrine reste tout de même assez lourd. Il n’y a qu’à regarder la cascade des fonctions appelées dés que l’on déclare un champs. Et ceci est executé à chaque appel d’une page. Ces nouveaux trucs à la activeRecord sont peut être sexy pour le développeur, mais ça reste des usines à gaz en environnement de production… Jelix a choisi une autre voie avec jDao (empruntée à Copix).
Tristan Rivoallan
3 novembre 2006
@françois : nous pourrons en effet discuter de tout ce la de vive voix :)
@laurent : si j’ai bien compris ce que tu dis là, et ce que je lis ici les jDAO fonctionnent comme Propel ?
Symfony proposera donc un ORM « ActiveRecord like » et un ORM à base de code autogénéré. Que demande le peuple ?
Et étrangement, c’est l’ORM basé sur active record qui semble être le plus performant.
Sur quelle couche d’abstraction s’appuient les jDAO ?
Mika
6 novembre 2006
Bonjour,
Tout d’abord j’aime beaucoup symfony, je l’utilise au travail sur environnement win32 et a la maison sur macos X.
Premierement, je me demandais si le projet continuai car contrairement a prado ou jelix, les dernieres news de symfony remonte un peu, donc c’etait pour savoir ce qu’il en est, et quid de la v1.0 un cadeau de noel ?
Deuxiemement, j’ai decouvert le yml et ai apprécié cette facilité de construction de la base de donnée ainsi que la creation des objets avec getter et setter, en plus c’est bien lisible le yml pour un schema de donnée.
J’espere que symfony va continuer sur cette voie, car il est bien partie ;)
Tristan Rivoallan
6 novembre 2006
Mika,
Symfony et bel et bien actif, il suffit de jeter un oeil à la timeline ;)
(sans vouloir troller, hormis les forums, je ne vois aucune source de news pour Jelix et Prado ?)
En ce qui concerne la 1.0 elle est vraiment en bonne voie et les différentes étapes nécessaires à la sortie d’une version stable d’un produit sont en train d’être mises en place.
Je pense que dans un avenir proche on aura même de la visibilité sur une deadline approximative.
Mika
6 novembre 2006
Je ne parlais pas de source news mais de news tout court: la derniere de prado date du 26 octobre, alors que la derniere date du 25 aout…
Je viens de voir la presence d’une timeline qui indique un dernier changement au 6 novembre
note: symfony est un projet francais, hors tout le site est en anglais, why ? a part quelques traductions de tutoriel ou d’aide…
En tout cas je suis bien content que le projet continue ;)
Si vous avez besoin d’aide, je veux bien participer :)
Tristan Rivoallan
6 novembre 2006
Mika,
la dernière version stable de symfony est en effet assez ancienne.
En ce qui concerne la traduction de la documentation, c’est un problème que nous soulevons dans l’article. Reporte-toi au commentaire de François (plus haut) pour un élément de réponse.
Peut-être pourras-tu aider à traduire la documentation lorsqu’un mouvement sera lancé dans ce but :)
blaise
13 mars 2007
Vachement sévères les gars.
En ce qui concerne la doc, j’ai rarement eu l’occasion d’avoir une doc aussi fournie en exemple. Tout y est expliqué ou presque.
J’adore et j’adopte en ce qui me concerne.
Si vous savez pas lire l’anglais, il serait temps de vous y mettre car faut être peu soucieux de l’évolution de vos application que pour encore penser même programmer en français!!
Apprenez dont l’anglais, çà coutera moins chère à tout le monde ;)
Question performances, il est certain que c’est une bien grosse armada pour un carte de visite mais qu’est-ce qu’elle aide pour un projet de gestion. Le découplage à la mode struts et spring des jsp est ecellent. l’orm généré par propel s’avère fonctionnel. les outils de générations sont pensés dans tous les sens, on ne fait plus qu’une fois le travail sur les données, que ce soit au niveau schéma, bd ou sql.
Je ne crois pas aller contre votre avis à ce sujet ;)
cependant, je trouve çà fort de se plaindre d’une doc anglaise…
Xavier Lacot
13 mars 2007
Blaise,
Nous avons essayé d’émettre nos critiques de la manière la plus prudente possible, car nous utilisons Symfony au quotidien et trouvons qu’il s’agit d’un excellent framework.
Concernant notre remarque au sujet de l’absence de traduction de la documentation, elle est l’écho de certaines remarques parues sur la mailing-list francophone de Symfony. Depuis novembre dernier, nous avons lancé un effort de traduction de la documentation en français car, même si nous savons parler anglais et sommes parfaitement à l’aise avec une documentation anglaise, nous estimons que ce serait dommage de priver des développeurs francophones de ce beau framework. C’est le moins que nous puissions faire pour contribuer au développement de Symfony.
Du reste, la documentation de Symfony est effectivement de qualité exemplaire, comme nous l’indiquons dans notre article ;)
amicalement,
xavier
Amsmams
10 avril 2007
Le titre de votre article peut faire penser que vous décriez symfony, mais en le lisant on vois que vous etes comme nous : vous aimez symfony et vous voulez qu’il soit le meilleur. J’utilise la version 1 du framework en mode sandbox depuis la mi-janvier et je doit reconnaitre que symfony fait fort. J’ai suivi les tutoriaux en anglais, mais c’est vrai que parfois des explications en fraçais seraient mieux…
Bon article!
fab
8 août 2007
Blaise,
Le problème de la doc fr est un demi problème car c’est vrai que la doc en anglais est vraiment complète.
Cependant on pouvait peut être attendre une version française plus étoffée car c’est une société française : sensio, qui est tout de même à l’origine de symfony
Jérôme
27 novembre 2008
Haha, vous êtes bien une boîte française. Se plaindre d’une doc anglaise, non mais quel toupet. Il vous manque un bérêt et une baguette sous le bras. Vous allez faire du consulting en marcel ?
Tristan Rivoallan
1 décembre 2008
@Jérôme : ce sujet a déjà été abordé ici, réfère-toi aux commentaire de Blaise et la réponse de Xavier Lacot datés du 13 mars 2007.
Robert
12 mars 2010
Merci pour ce billet intéressant! Il faudrait le mettre à jour avec les dernière version de Symfony, actuellement 1.4 et 2.0 en vue déjà!
Doctrine devient un standard.