29 Responses to “Le difficile choix d’un framework php…”

1. pascal Says:
   le 29 April 2008 à 16h26

   pour ma part, c’est symfony, car :
   _ la ligne de commande génère beaucoup de choses
   _ le scaffolding rapide
   _ la configuration en yaml évite beaucoup de codage
   _ la doc volumineuse
   _ le champ des problématiques gérées par le FW : i18n, sécurité, …
   _ le nombre de modules impressionnants
   _ le routing d’url
   _ l’interaction avec la DB, récupération du schéma ou génération du SQL simplement
   _ la communauté ( docs, forum, pérennité du FW )

   les difficultés :
   _ beaucoup de fichiers, mais une arborescence limpide
   _ la prise en main, il faut s’accrocher, bosser, tester, se planter… disons une bonne semaine en dilettante pour faire des formulaires de A à Z

2. Sarah Haïm Says:
   le 29 April 2008 à 16h42

   Si j’ai tout compris, le framework sera utilisé en interne pour générer l’appli, et donc la connaissance de l’outil sera le critère de recrutement de collaborateurs futurs.
   J’ai un collègue fan de Zend Framework, et pour ma part, je me spécialise sur Symfony

3. Oli78 Says:
   le 29 April 2008 à 16h43

   Je serai partisan de Jelix car quelqu’un qui connait Daniel Glazman et Tristan Nitot ne pas être foncièrement mauvais.

4. kilgore Says:
   le 29 April 2008 à 16h48

   Symfony également. Seul reproche, la lenteur !

   Je ne suis pas du tout de ton avis concernant ZF, il est très très léger puisque tu n’utilises que les composants qui t’intéressent et surtout, tu peux organiser ton code comme bon te semble (tes fichiers, tes dossiers). C’est à mon avis le sommet de l’agilité et si je devais démarrer un nouveau projet “important” en PHP aujourd’hui, je partirai sans hésiter vers ZF!

5. Mathias Says:
   le 29 April 2008 à 18h10

   Salut, moi j’utilise Cake Php, pour son coté modulaire et sa simplicité d’approche et aussi parce que c’est du RoR like…

   Pour sa mise en cache des requete sql, pour son outils de scaffolding qui se met en place en une variable et pour l’absence de fichier xml !!

   Et aussi pour sa version 1.2 (hélas en core en beta mais deja rock solid !!)

   cheers

   Mathias

6. lenny Says:
   le 29 April 2008 à 19h46

   Zend Framework sans hésiter…

   Quelque site fait avec :

   http://magentocommerce.com // modulaire
   http://fotolia.com // fort volume de donnée et sécurité
   http://maximiles.com // sécurité et mailling

   Une implémentation de départ :
   http://code.google.com/p/basezf/

   Documenter et rigoureux et une communauté de professionnels.

7. kilgore Says:
   le 29 April 2008 à 21h56

   @lenny bien vu BaseZF !

8. p4bl0 Says:
   le 29 April 2008 à 22h35

   J’ai récemment dû faire ce choix pour un projet avec un ami, sauf que notre choix ne se limitait pas à PHP, ou a aussi tester Ruby On Rails, Merb, et d’autre framwork Ruby (il fait du principalement du Ruby et moi principalement du PHP).

   Au final, en lisant plusieurs articles, en testant les frameworks etc, on a choisi PHP. Parce qu’il demande apparemment moins de ressource permet d’être plus “scalable” sur une appli web.
   On a essayé CakePHP, CodeIgniter, Zend Framework et Symphony et on a juste lu les features, doc et tutos pour quelques autres cités dans cet article. Notre choix s’est porté sur Zend Framework. Surtout parce que la façon de coder me convient particulièrement bien, et aussi parce qu’il donne beaucoup plus de liberté, par exemple dans l’organisation de ses fichiers en obligeant pas dès la mise en place à avoir 15 dossiers contenant pour la plupart déjà des fichiers et sous-dossiers sur plusieurs niveaux !
   On a aussi choisi Zend Framework pour les outils et fonctionnalités qu’il offre et qui corresponde parfaitement à ce qu’on cherche

   Et j’ai étais étonné de voir dans l’article que le Zend Framework est “lourd” car je n’ai pas eu cette impression et je n’ai pas le souvenir d’avoir déjà lu ça (mais je n’ai pas encore lu tout les articles de comparaison que tu cites, je vais m’empresser de le faire d’ailleurs).

   Je rejoins donc les avis de kilgore et lenny (merci pour les lien et BaseZF, je vais regarder ça de plus prêt).

   Mais j’aimerai savoir ce qui fait que ZF est lourd par rapport aux autres, il y a des benchs ?

9. Fabien Says:
   le 29 April 2008 à 23h05

   Sinon le choix n’est pas limité à PHP, ça vaut vraiment le coup de tester Django (en Python)

10. nautilebleu Says:
    le 30 April 2008 à 08h08

    Pour créer notre LMS, nous avons choisi symfony. A l’époque ZF était encore à ses débuts. Nous voulions un outil très évolutif, ce qui excluait tout ce qui tourne avec PHP4 (CakePHP, CodeIgniter) pour profiter à fond des fonctionnalités de PHP5 .

    Le point déterminant pour nous a été la doc. Symfony était (est ?) le seul a avoir une doc qui tienne la route.

    Nous n’étions pas limité à PHP, même si nous connaissions ce language et pas Ruby ou Python. Nous avons tout de même testé RoR et Django. RoR a été recalé faute de docs corrects. A l’époque nous avons eu un peu peur de nous lancer dans Python, d’autant qu’il y avait aussi la problématique de l’hébergement. Si c’était à refaire, je pense que je choisirais Django aujourd’hui.

11. Pascal V Says:
    le 30 April 2008 à 09h04

    Un truc m’intrigue. Vous êtes déjà bien avancé dans FindAWine. Et vous voulez aujourd’hui adopter un framework ? Vous faisiez donc tout à la main avant ? ou vous en aviez un qui vous a deçu au point de recommencer avec un différent ? Quel est l’élément déclencheur de cette démarche ?
    Par ailleurs, Zend et Zoop (surtout Zend) me semblaient des stars du milieu et dans ta description ils passent rapidement à la trappe. Ils sont donc déjà out ?

12. p4bl0 Says:
    le 30 April 2008 à 09h13

    @Pascal V : peut-être qu’ils suivent en partie les guidelines de Getting Real qui conseil de d’abord créer l’interface presque comme elle sera au final avant de coder ce qu’il y a derrière.
    http://getreal.37signals.com/ (je l’ai mais je ne l’ai pas encore lu, juste feuilleté pour le moment ;-))

    Sinon j’aimerai aussi une explication sur le passage à la trappe si rapide de ZF, surtout que maintenant j’ai lu aussi les articles linkés dans ce post et je n’ai toujours pas lu que ZF était lourd… On peut nous expliquer ?

13. p4bl0 Says:
    le 30 April 2008 à 09h15

    Au temps pour moi, je n’avais pas essayé mais apparemment findAWine fonctionne déjà… Ben du coup je me pose les même questions que Pascal V. hu?

14. babozor Says:
    le 30 April 2008 à 09h43

    Pour Zend Framework, après test effectivement il est pas lourd Ultra MeaCulpa… je l’avais testé il y a quelques mois/années et il m’avait semblé lourd et j’étais resté sur cette impression (je me flagelle dès que j’ai deux minutes)

    Pour répondre à ta question Pascal, effectivement on pourrait très bien continuer sans framework mais pour plusieurs raisons on risque de basculer sur un framework (a définir sous peu), pourquoi?
    1. une norme commune: aujourd’hui on est 3 et bientôt 5 voir presque 6 à coder sur le projet et on a besoin d’une norme structurante. Jusqu’ici on travaillais avec une norme et mon micro framework (ultra basique mais qui marche bien) mais que certains ne respectaient pas à la lettre.
    2. MVC: par faute de temps pas pu mettre en place la logique MVC, ce qui dans le futur risque de s’avérer génant
    3. Pour se simplifier la vie: aujourd’hui on code tout, même des vieux BacksOffices merdiques que certains éléments de certains framework pourraient faire à notre place.
    4. Sécurité: même si j’essaye d’avoir la tête à droite à gauche, certains problèmes d’injection (MySQL ou XSS) m’échappent (et pleins d’autres aussi je suis sur), et passer par des fonctions bullet-proof d’un framework permettraient d’y remédier

    On pourrait très bien continuer sans FW (on l’a fait pendant 6 mois avec des résultats bien au delà de mes espérances en arrivant chez findawine) mais on a besoin aujourd’hui de se structurer pour assurer les développements qui arriveront demain.
    Je sais pas si j’ai été super clair…

15. babozor Says:
    le 30 April 2008 à 10h46

    un article connexe à ce sujet, mais qui résume bien à mon sens la situation: http://blog.developpez.com/index.php?blog=126&title=php_framework_vs_just_php

16. laotseu Says:
    le 30 April 2008 à 13h06

    A titre personnel, PHP me gonfle. Je peux comprendre ce choix pour des applis destinées à être déployées facilement sur des hébergements mutualisés grand public, mais dans le cas d’un dev spécifique avec un hébergement décent (ie: en ayant la main sur les machines hôtes), je préfère de loin une solution basée sur Ruby ou (encore mieux AMHA) Python. Par expérience, Django est une *très* bonne solution.

17. Sarah Haïm Says:
    le 30 April 2008 à 13h59

    @laotseu : je me suis laissée dire que Ruby ne tenait pas la charge, mais je ne suis pas sysadmin.

18. kilgore Says:
    le 30 April 2008 à 14h06

    @Sarah Haïm on dira surtout que les mésaventures de Twitter ont montré qu’il n’était pas si facile de “scaler” une appli RoR qu’on peut le croire. Beaucoup disent d’ailleurs que si Twitter avait été développé en PHP, il utiliserait beaucoup moins de ressources.

19. laotseu Says:
    le 30 April 2008 à 22h18

    @Sarah: je me suis laissé dire beaucoup de chose (en bien ou en mal) de beaucoup de technos, et je ne les ait pas forcément vérifié. Maintenant, effectivement, l’expérience de certains sites montre qu’il peut y avoir des difficultés à gérer une montée en charge importante pour un site basé sur Rails. C’est d’ailleurs une des raisons pour lesquelles ici on se tourne plus vers Django (et qu’en ce qui me concerne je commence à explorer Erlang et Yaws), au moins pour des projets appelés (si tout va bien) à être confrontés à ce type de problèmes. D’un autre côté, tous les projets ne sont pas nécessairement concernés. Une install typique de phpMyAdmin, par example, n’a pas ce genre de soucis. Encore une fois, c’est une question de savoir choisir un outil adapté…

    @kilgore: PHP est un langage, Rails un framework. Vu l’utilisation typique de PHP, il faudrait comparer avec un dev en Ruby sur un modèle ’server page’ - ce qui est très différent. Dans ce contexte, je ne pense pas que Ruby soit intrinsèquement inférieur à PHP (au point de vue de perfs et de la scalabilité). Il serait par contre intéressant de comparer CakePHP à Rails, et là je doute que le premier s’avère vraiment plus intéressant (pour le moment en tous cas, ce n’est pas ce qu’il ressort de notre expérience avec l’un et l’autre sur des charges à peu près comparables).

20. Hugo Says:
    le 1 May 2008 à 09h10

    Salut,

    Pour ma part j’utilise Symfony pour les raisons suivantes principalement :

    - RAD et agile
    - Full PHP5
    - Abstraction de BDD
    - Full MVC
    - I18N et L10N
    - Scaffolding
    - Générateur de backoffice
    - Sécurité
    - Fiabilité
    - Cache intégré
    - Entièrement configurable
    - Testé
    - Maintenu quotidiennement par Sensio Labs
    - Dispose de nombreux plugins prêts à l’emploi
    - Nombreux helpers intégrés en natif (Date, Monnaie, Url, Texte…)
    - Entièrement extensible avec nos propres classes existantes
    - Repose sur des bonnes pratiques (DRY, KISS…) et design patterns (ActiveRecord, Singleton…)
    - …

    Mais pour moi son plus gros point fort et ce qui m’a conforté dans ce choix, c’est SA DOCUMENTATION et la COMMUNAUTE qui tourne autour. Grâce à cela, on n’est pas perdu avec Symfony. Et c’est sans doute pour ça aussi que Symfony est devenu si populaire.

    Néanmoins Symfony a des défauts. Et il faut en parler et en avoir connaissance pour choisir son framework (surtout dans le cas du développement professionnel). Symfony a le vilain défaut d’être assez lourd. Il charge déjà une 40taine de classes au démarrage et utilise également l’ORM Propel, réputé pour sa lenteur. Néanmoins, un plugin propose d’utiliser l’ORM Doctrine, beaucoup plus performant et intuitif à utiliser, mais qui est à ce jour encore en phase de développement. Autre point faible : son temps d’adoption. Développer avec Symfony c’est effectivement fun et rapide quand on connait le framework mais il faut clairement un à deux mois de manipulation intensive pour en comprendre les rouages et pouvoir être à l’aise ensuite.

    Actuellement je l’utilise à titre personnel donc je n’ai pas de contrainte monétaire. Mais j’ai essayé de convaincre mes dirigeants (agence web dans laquelle j’officie) d’adopter Symfony pour structurer nos développements et les rendre plus rapides. Sachant que la société a doublé d’effectifs (en poste de développeurs) en l’espace de 6 mois. Nous sommes passés de 2 à 5 développeurs, et nous envisageons peut-être de nous agrandir dans les 6 / 8 mois à venir. Malheureusement, ils n’ont pas été convaincus par ce framework pour la simple et bonne raison qu’à ce jour ils ne veulent pas changer leurs habitudes de développement et prendre du temps (surtout !!!) pour apprendre à utiliser un framework.

    Pour en revenir rapidement sur Symfony en lui même, deux versions existent aujourd’hui : il y’a la branche 1.0 et la branche 1.1. La première (et aussi celle que j’utilise) est stable depuis longtemps et continue d’être maintenue. De l’autre côté, la version 1.1 s’apprête à voir le jour dans sa première version Release Candidate. Il faut savoir que Symfony 1.1 a subi d’importants changements par rapport à la 1.0. Au programme des changements :

    - Remaniement de l’organisation des objets du coeur du framework (Dispatcher, Context, Request, Response, User…). Suppression des singletons.
    - Intégration du nouveau sous-framework indépendant de création et de validation de formulaire. C’est outil est disponible comme sous-framework indépendant et sous licence MIT. Il est donc possible de l’utiliser en dehors du framework Symfony.
    - Amélioration du support de l’internationalisation
    - Accroissement des performances
    - Intégration d’un nouveau parser YAML qui retourne des exceptions claires pour le développeur. Sur Symfony 1.0 c’est SPYC qui est utilisé. En cas d’erreur, le debbogage devient particulièrement compliqué…
    - Refonte complète de l’interface d’utilisation de symfony en lignes de commande (CLI).
    - Donner la possibilité au développeur d’organiser les fichiers comme il le souhaite, comme pour Zend Framework.
    - …

    Bref, pas mal de nouveautés qui devraient rendre les développements avec Symfony encore plus attractifs et rapide. La communauté attend cette nouvelle version (stable) avec une grande impatience.

    Enfin pour terminer sur Symfony, je vous informe d’un petit plus assez sympa. Un membre de la communauté à développer un plug-in Eclipse pour Symfony. Il s’agit de Symfoclipse. Celui-ci permet de développer avec Symfony dans l’IDE Eclipse et de s’abstraire de l’interface en lignes de commande. Symfoclipse le fait pour vous à la demande. Je suppose qu’il existe ce genre de plug-in pour les autres frameworks. En tout cas, pour Zend Framework c’est le cas. Zend vient de publier il n’y a pas si longtemps, un plugin Eclipse pour utiliser Zend Framework. Néanmoins ce plugin est payant contrairement à Symfoclipse.

    J’espère que mon long speech de retour d’expérience avec Symfony vous sera utile dans le choix de votre nouveau framework. Je vous encourage vivement à utiliser Symfony car c’est un réel plaisir à utiliser

    ++

    Hugo.

21. Palleas Says:
    le 1 May 2008 à 09h23

    Je vais me faire l’avocat du diable mais je n’aime pas vraiment les frameworks PHP. Ok c’est un gain de temps non négligeable mais j’ai l’impression d’apprendre un nouveau langage, je préfère de loin m’en inspirer pour coder MES classes :).

22. Laurentj Says:
    le 1 May 2008 à 14h09

    @babozor : je pense qu’il y a un point que tu as oublié dans la réèlle prise en compte d’un framework : la façon dont est structuré un projet. Et c’est ce qui différencie à mon sens un vrai framework d’une simple bibliothèque de classe. Rappel : framework = cadre de travail. Un framework DOIT imposer un cadre de travail.

    Par exemple, Zend Framework n’est pour moi pas un framework, mais une simple bibliothèque (un PEAR en plus propre). Comme l’a rappelé plus haut un des commentaire, il n’impose pas du tout la façon dont on organise les fichiers. Cela peut paraître un avantage, car on a la liberté de faire comme on veut, mais c’est à mon sens un gros inconvénient, surtout quand on travaille en équipe. En effet, cela veut dire que d’un projet à un autre, l’arborescence des fichiers change, et donc le développeur peut perdre du temps à retrouver les fichiers qu’il faut modifier quand il “débarque” sur un projet existant dans lequel il doit faire une évolution ou une correction de bug.

    Au contraire de Zend Framework, Jelix impose une certaine arborescence : découpage en module, arborescence précise dans les modules. Résultat : on sait tout de suite où chercher les templates, où chercher les classes métiers, où chercher les contrôleurs etc, MEME SI ON NE CONNAIT PAS LE PROJET. Pour la maintenance et l’évolution d’une application sur le moyen et long terme, c’est quelque chose de très bénéfique. C’est quelque chose que j’ai pu expérimenter et observer sur de nombreux projets clients, en SSII, depuis le tout debut de Copix (2001, alors qu’il n’était pas encore rendu publique), et les développeurs débarquant dans un projet qu’ils ne connaissaient pas, fait avec Copix, étaient rapidement opérationnels et savaient tout de suite où regarder dans les sources pour corriger tel ou tel truc. Et c’est pour cela que j’ai continué d’imposer une arbo avec Jelix.

    Une bibliothèque qui n’impose pas un cadre de travail, donc une organisation claire et stricte dans les fichiers d’un projet, n’est pas un framework. Ça reste une simple bibilothèque.

    @Oli78 : merci pour le compliment

23. Metal3d Says:
    le 4 May 2008 à 12h37

    Avec tout le respect que je vous dois, je ne suis pas d’accord avec un point de l’article. Peut-être pace que je suis un membre actif de la Copix Team

    La phrase que je contre est:
    - Copix, parceque Jelix semble une évolution plus maintenue et plus avancée de Copix

    Il suffit que vous regardiez les versions qui tombent régulièrment, les évolutions techniques que Copix apporte… Jelix est largement moins avancé que Copix et ce en bien des points.

    Attention, je n’attaque pas le projet Jelix. Laurent fait un très bon travail et son framework est un très bon fork de Copix. Mais en tout honnêteté, l’idée que Jelix soit plus maintenu que Copix vient d’une ancienne période de transition que Laurent a mis en avant pour promouvoir Jelix.

    Cette période est révolue depuis bien des mois.

    En tout cas, très bon article.

24. e-media Says:
    le 6 May 2008 à 11h06

    Le choix d’un framework est subjectif, un tel préfèrera ceci ou celà…

    En ce qui me concerne, j’ai choisi JELIX car il est simple à appréhender, il est très bien structuré et c’est en ce sens un vrai framework.

    Il permet une approche MVC, il est robuste et est optimisé pour des serveurs a fort trafic…

    Le framework est evolutif (plugin), il permet l’utilisation des DAOS (configuration via XML, et fichiers pouvant être généré par script en ligne de commande) ou de créer ses propres requêtes grâce à jDB ou au sein de la factory, il possède des outils pour créer les formulaires html jForms paramétrables en XML (très souple et efficace).
    Il permet de générer des PDF, d’utiliser SOAP, gestion des logs, UTF-8 et locale,… j’en passe et des meilleures…

    Et le must c’est que la documentation est très bien faite et les exemples sont complets…

    Le temps d’apprentissage est plus ou moins rapide. Il dépend de la maitrise des technologies webs et des notions ou connaissances en programmation objet…
    Mais dans tous les cas JELIX vous simplifiera la vie…

    Aujourd’hui la communauté autour de JELIX, ne cesse de grandir…
    Les versions sortent régulièrement depuis que je m’y suis mis.
    Précision importante : Laurentj reste ouvert aux évolutions et contributions si elles sont pertinentes…

    Un dernier mot, essayer JELIX, c’est l’adopter…

    e-media

25. richard Says:
    le 16 May 2008 à 16h03

    et qu en est il de ezcomponents?

26. Olivier Mansour Says:
    le 16 May 2008 à 19h04

    pour info, un livre blanc sur les framework php vient de sortir chez Clever Age :

    http://www.clever-age.com/veille/blog/frameworks-php-pour-l-entreprise-quelques-criteres-de-choix.html

27. tenshu Says:
    le 16 May 2008 à 23h19

    Nous avons choisis Symfony dans notre agence (on vient de finir http://www.tarakbenammar.com/).

    Perso j’aurais penché pour django, par pur curiosité envers python =)

    SF est super sur beaucoup de point, même si la doc est très souvent limite, on se dit souvent “bordel bordel mais pourquoi ceci cela” et souvent la réponse est simplissime mais mal/pas documentée. Il faut le temps de ce roder c’est tout.
    Petite déception au niveau de l’i18N surtout côté backoffice …

28. Metal3d Says:
    le 17 May 2008 à 18h04

    @e-media: Encore une fois, vous devriez regarder du coté de Copix. Les DAOs sont automatiques, rien à faire pour qu’elles fonctonnent. Y’as des dixaines de modules prêts à l’emploi.

    Il est au moins aussi souple que Jelix, plugins simples et efficaces, des libraires très performantes… et j’en passe… Son évolutions et sa communauté est très large. Le nombre de sites développés sous Copix est conséquent et il est en constante évolution. Le status de Copix est pérenne et professionnel.

    Encore une fois, je ne viens pas taper sur Jelix, mais défendre Copix contre l’image qui a été véhiculée. Image qui est le résultat d’une mauvaise période dantant de 2005-2006. Une année sur les 6 ans de développement de ce framework qui nous joue des tours en terme d’image de marque. C’est fort dommage. D’ailleurs LaurentJ avait quitté l’équipe Copix dans ces moments en partie à cause de cette période trop calme.Mais cela date de 2 ans et cette période est largement révolue… j’ai encore du mal à comprendre pourquoi cette fausse image reste si présente.

    Copix est aujourd’hui bien plus avancé que beaucoup de ces concurents en terme de noyau et librairie. Et les évolutions pour la 3.1 sont au delà de ce que j’imaginais.

    Qu’à cela ne tienne, nous avons une vaste communauté, un nombre de site utilisant Copix très important, Inutile de défendre encore l’image, nous avons les résultats

29. Truffo Says:
    le 10 July 2008 à 11h28

    Personnellement, je trouve que le framework qui permet aujourd’hui d’être le plus efficace est le Zend Framework dans sa version 1.5. Je l’ai longtemps boudé du fait des réproches que l’on trouve à droite à gauche, et que je trouvé justifier mais en réalité ce sont des avantages indéniables.

    D’une part, il propose une architecture par défault pour la couche MVC, mais on peut très bien la modifier et ceci très simplement.

    D’autres part, il offre l’immense avantage de pouvoir l’utiliser composants par composants, ce qui permet de faire une transition en douceur par rapport aux habitudes des développeurs. Ce n’est pas du tout ou rien comme dans les autres.

    Chaque composants offre plusieurs manières de les utiliser, ce qui permet de s’adapter à la tache à accomplir et permettre à tout un chacun de l’utilisé indépendemment de son niveau et de sa connaissance de l’outil.

    Aussi, la qualité de la documentation est vraiment impressionnantes.

    Le seule bémol c’est le scaffolding qui manque, mais faire un script qui crée des fichiers et génère du texte c’est pas la mer à boire non plus.

Laissez un commentaire