Premier regard sur le framework Zend
Par Laurentj le mercredi, mars 8 2006, 00:58 - Geek-log - Lien permanent
Zend, la société qui dirige le développement du moteur de PHP, vient de publier une toute première version, 0.1.1 de son framework PHP : Zend Framework.
J'ai lu la doc, jeté trés rapidement un coup d'oeil sur les sources, et lu ce tutoriel. Mise à part leur classe Zend_db_object qui est une pâle copie d'ActiveRecord de Ruby On Rails, c'est un framework trés trés trés classique et pas vraiment innovant, par rapport à ceux qui existent déjà depuis pas mal de temps (il y a des trucs plus sympa dans Copix/Jelix : meilleure organisation des fichiers d'une appli, découpage en module, système évènementiel, Urls automatiques etc). Bref, pas de quoi s'extasier.
Ce n'est toutefois qu'une version 0.1.1. Donc on peut s'attendre à pas mal d'évolutions pour le futur. Éspérons alors qu'il apportera de véritables avancées en matière de framework.
Commentaires
je crois vraiment que ce qui manque à TOUS les frameworks qui veulent concurrencer Rails c'est de proposer un tuto qui montre qu'en 5 minutes tu fais un truc qui tourne
Sinon le site est naze au possible, impossible d'etre attiré par le framework.
Adepte de Copix, je migre doucement vers Rails et je dois dire ben... que c'est vraiment vraiment bien !
(et en tous cas dans les projets ou j'ai besoin de Copix, celui ci ne semble menacé que par Jelix, et pas par Zend
)
Perso, je vois plus ce que tu appelles un framework comme une alternative à Pear qu'autre chose. Un ensemble de bibliotheques qui prennent en charge les fonctionnalités standards d'une application web un peu évoluée et qui permettent de gagner du temps, à la fois parce qu'elles font de l'abstraction de haut niveau et parce qu'il n'y a pas besoin de réinventer la roue. Un framework c'est un peu plus que cela à mon sens. Un framework oblige le developpeur à suivre un chemin, un rail (RoR ne s'appelle pas RoR pour rien) dans son développement, fige l'arborescence des fichiers, la manière de faire les choses. Ca permet donc d'aller vite, mais ca manque de souplesse sur des choses qui sortent de l'ordinaire. Maintenant, je n'ai fais que parcourir rapidement le framework, et comme dans le cas de pear, la qualité du code est à mon sens moyenne, ou du moins manque d'optimisation. Certaine chose, notament le pdf sont à suivre du coin de l'oeil quand meme, et comme tu le dis, c'est une 0.1.1... La doc n'est d'ailleur pas synchrone par rapport au source... Ce qui me gene, c'est que ce "framework" risque de tuer pas mal de solution existante, sous pretexte que ca vient de Zend donc c'est forcement magique et que ca ne peut que marcher correctement et meme faire le café... En somme je redoute le syndorme "C'est microsoft, c'est forcement bien", en faisant s/microsoft/zend/g. Plutot que perdre du temps la-dessus, zend aurait mieu fait de filer un coup de main au core php pour sortir une version de PHP 5 qui fonctionne correctement.
Je ne comprend pas ta phrase
Tout à fait d'accord avec toi. Copix ou Jelix sont de véritables frameworks en ce sens (voir la doc de Copix, le premier chapitre est consacré à expliquer cela). Et ils vont beaucoup plus loin que ne va Zend, ou même Rail sur certains points (je trouve que rail n'est pas aussi structurant que Copix/Jelix). Et je suis toujours indigné quand on désigne Pear ou autre simple ensemble de classes comme des frameworks. Beaucoup confondent bibliothèque et framework.
Laurent > Rails c'est vrai n'est pas super structurant... dans ses spécifications.
Mais, à moins que je suis un vrai mouton, je ne me pose que très rarement la question de "où mettre ce morceau de code". La structure serait elle intrinsèque ?
Pour Pear, pour moi c'est un vrai problème (qui a dit plaie?) Y a des trucs bien, mais aucun packaging global, tu sais pas quoi utiliser, les hébergeurs s'en cognent, enfin c'est pas la fête.
La question est moins "où mettre ce morceau de code", mais plus "où se trouve tel morceau de code". Rares sont les développeurs qui pensent à la maintenance, à la reprise de projet etc. Or, tout ceux qui ont une certaine experience en SSII par exemple, qui sont souvent amené à reprendre le code des autres, soit pour le faire évoluer, soit pour corriger des bugs, sont souvent confronté à ce problème : retrouver le code (et vite) correspondant à telle partie de l'application qu'il faut modifier.
La structure modulaire de Copix/Jelix, l'organisation structurée des fichiers, imposée, favorisent je pense à diminuer ces problèmes de maintenance (en tout cas, tout ceux qui ont utilisé Copix, dont moi évidement, ont pu le vérifier maintes fois). Et c'est un peu plus évident dans Jelix où j'ai simplifié quelques trucs, fais le ménage, par rapport à ce qui existe actuellement dans Copix.
dans mon esprit c'était bijectif. Quand tu connais le framework, tu sais où mettre le code, et où le trouver.
Mais je maintiens que Copix/Jelix est très bien fait. Et que Rails aussi (et il bénéficie de Ruby, alors que bon PHP (<5) c'est pas toujours un cadeau
)
Pour moi, le Zend Framework dans sa version actuelle ne merite pas son appellation de framework.
C'est un équivalent de PEAR.
Fch : ah ok, je comprend mieux ta phrase.
En fait, c'est tout à fait ce que j'ai pensé aprés mon analyse de Zend Framework. Ma première réaction fut : c'est un Pear 2.
Je ne l'ai pas dit car il y a tout de même ces 2-3 pauvres classes pour le MVC, qui structurent un tout petit peu une application. On verra dans quelques mois si il mérite véritablement le nom de framework
Je ne crois pas que Zend va structurer son framework sur la base du pattern MVC. Rasmus est contre la mise en oeuvre de ce principe, car pour lui c'est un goulet d'etranglement qui empeche la montée en puissance d'un site qui met en oeuvre php (cf http://toys.lerdorf.com/archives/38-The-no-framework-PHP-MVC-framework.html). Bon apres je peux me tromper. Mais quand j'en avais discuté au dernier forum php à paris, j'avais bien compris qu'il s'orientait à cette epoque vers un PEAR plus "professionnel" et qui profiterais de l'experience de Zend avec le langage, plutot que vers un framework en tant que tel.
Le petit exemple de Rasmus (voir commentaire de fch) est tres interessant. Si on le lit et on lit la doc/utilise aussi les developpements faits en Python comme django, cela donne pas mal de bonnes idees sur les choses a faire et ne pas faire. Mon probleme avec les framework (et entre autre mon projet Plume CMS) c'est qu'on finit par charger en memoire un "gros paquet" de choses avant de repondre a une simple requete. On parle souvent d'utiliser un cache du bytecode, mais en pratique la tres grande majorite des sites ne disposent pas de cette fonctionnalite.
Sinon, Laurent, ta classe pour compiler un gabarit de Jelix est superbe. L'idee de reprendre le tokenizer de PHP est "tip top". J'admire.
Oui... mais non.. Avec PHP5, c'est moins vrai si le framework utilise l'autoload comme dans Jelix et optimisé pour ce système : seules les classes vraiment utilisées sont chargées.
Cependant, je suis d'accord avec toi, c'est un truc que je me suis rendu compte avec Copix. C'est pourquoi dans Jelix, même si il y a l'autoload, j'essaie de minimiser au maximum la quantité de code, j'essaie d'optimiser au maximum, de trouver des algorithmes, des façons d'implementer qui évitent d'avoir à recourir à quantité de ligne de code. Tiens, par exemple, pas plus tard qu'hier soir, j'ai viré ce fichier actions.xml de déclarations d'action. Et hop, deux classes en moins.
Eh eh
Merci !
Je suis en train de tester Elegantk et je trouve que cet environnement de développement .ORG n'a rien à envier à Zend Framework.
nbaz
Bonjour,
Personnellement j'utilise le nouveau framework Noas PHP (http://noas.sourceforge.net). C'est de son cahier des charges que Zend c'est inspiré pour son framework. La documentation est complète ( mais pas en anglais, c'est peut être ce qui a déplus à Zend). Il est prévu pour réaliser de gros projet et pour au cycle de développement ( travail collaboratif, maintenaince, test unitaire, bentchmark, etc).
J'ai des doutes que ce soit vrai. D'une part parce que Zend utilise des design patterns qui sont *extremement* courant. (à la limite, même si c'est faux, on pourrait dire que Zend s'est inspiré de Copix, qui est beaucoup plus vieux que Noas). Et d'autres part, vu les exemples de noas, la façon de coder est largement différente (fichier xml exchange etc.. y a rien de tout ça dans zend).
Ensuite, sur le site de Noas, il parle de trucs "innovants" alors que ce sont pour la plupart des principes que l'on retrouve depuis des années dans d'autres framework. Ex : le mapping R/O en xml, on le trouve dans Copix depuis quelques années (et donc dans jelix); La syntaxe des templates, l'organisation des fichiers d'un projet et beaucoup de chose au niveau de l'API sont inspirés largement de JAVA/JSP/Servlet. Bref, Noas n'est pas vraiment plus original que les autres frameworks en général.
(je ne dis pas non plus que Jelix est plus original que Noas hein; quoique..
)
Merci pour ton analyse, au moins tu prends la peine d'argumenter "techniquement" et ça c'est appréciable.
J'aime bien ce que tu dis sur la différence entre Librairie et Framework. Je pense également, du moins dans ce premier jet, que Zend Framework ressemble plus à une libraire qu'à un Framework.
Cependant, je ne suis pas trop d'accord sur d'autres points :
Je suis peut-être un peu allez fort, mais il faut savoir que Zend à reçu l'idée du projet Noas en 2004 (alors que Zend Framework n’étais même pas en prévissions) où était d’écrit un véritable framework ( et pas une librairie ) et ses activités annexes ( ex : plugin-eclipse ). Je suis d’accord que dans la réalisation, les choix techniques sont différents, mais il existe quelques petites similitudes ( j’exagère ). C’est plus dans le concept du projet.
Il est évident que tous les frameworks possèdent des points communs car ils sont à l’origine des mêmes besoins. Les différences se font sentir dans les implémentations et dans les finissions. Sauf si le framework est assez classique, ce qui n’est ni le cas Jelix, Noas ou encore Prado, c’est pour les besoins/fonctionnalités plus spécifiques qu’il faut juger. Chacun à sa petite part d’originalité ( du point de vu PHP et pas nécessairement innovant, quoique …) .
Je ne pense pas que le commun des mortels développeurs PHP sont accoutumée à mapper des objets métiers à l’aide de XML ( description XML ). De plus je ne pense pas que ce soit un bon exemple de trucs "innovants" dans Noas. J’aurai plutôt dit :
Et j’en passe…. Il faut réellement l’utiliser pour explorer son potentiel.
Que reproche t on au pattern utiliser dans J2EE. Ils ont déjà fait leur preuve à tous les niveaux (organisation, maintenance, souplesse, modularité, etc.). Je suis d’accord que l’architecture des fichiers du projet ressemble à J2EE, d’ailleurs quitte à en choire une, . Mais à part ça et le fait que la réflexion est utilisé à outrance ( réellement disponible avec PHP5, donc pas aussi vieux que ça ) qui le rapproche plus des frameworks Java que ceux en PHP, Noas est développez en PHP5 pour PHP5 avec l’esprit PHP5. L’utilisation de pattern déjà éprouvé sur les autres langages ne peut qu’améliorer sa qualité.
Il faudrait laisser à Noas sa part d’originalité. La notion de « plus » est bien trop subjective et dépend de ce que l’on attend d’un framework. Mais Noas possède une architecture et une gamme de fonctionnalités techniques que l’on ne retrouve pas chez les autres que les développeurs et chefs de projet apprécieront.
Je finirai en vous demandant à tous, est ce que Zend n’aurait pas plus intérêt à soutenir les très bon framework, pour qu’il y en ait au moins une dizaine de très très au qualité ( il faut toujours laisser le choix aux utilisateurs et un peu de concurrence ça ne tue pas ! ), au lieu de proposer un qui, pour le moment, n’apport rien de plus que les solutions existantes et va peut être mettre un terme à l’engouement général (pas seulement des développeurs PHP) pour le PHP ?
ok merci pour ces renseignements complémentaires.
Zend n'est pas une société philantropique (aucune entreprise ne l'est). Elle est là pour faire de l'argent. Réaliser et proposer son propre framework va lui permettre d'apporter de la valeur ajoutée à son offre, d'offrir à ses clients du support, des services, sur un produit qu'elle maîtrise et qu'elle fait évoluer à sa guise.
Bref non, à mon avis, elle n'a aucun interet à supporter les autres frameworks, même si elle clame haut et fort qu'elle ne veut pas tuer la concurrence.. Mais à mon avis, quand la 1.0 sortira, ça va faire mal. Beaucoup de projet de framework vont mourrir à mon avis.