mars
2010
Un article de Nighty
Se retrouver face au Zend Framework pour la première fois impressionne. On a beau avoir lu toute la documentation possible, acquiescé d’un signe de tête convaincu à chaque fin de paragraphe pour marquer l’appropriation de chaque concept, il se trouve que le jour J, on se retrouve comme un gallinacé face à un ustensile de cuisine : on a beau avoir l’intime conviction que ça va nous être indispensable, on se demande par quel bout le prendre.
Quiconque aura tenté l’expérience de but en blanc l’aura constaté : développer un projet de A à Z basé sur le Zend Framework revient à répéter inlassablement les même portions de code. S’approprier le Zend Framework passe à mon avis par la conception de sa propre bibliothèque (même light) afin de factoriser les éléments couramment utilisés.
Cet article n’a pas but de vous convaincre de quoi que ce soit, je vous expose juste une « façon de faire » qui jusqu’ici m’a plutôt bien réussi sur des projets de taille modérée. Il parle de concepts propres à Zend Framework 1.8 et ultérieurs : namespaces, application, ressources…
Si vous n’êtes pas familier avec ceci, je vous conseille de jeter un oeil ici : http://framework.zend.com/manual/en/zend.application.html
Et pour les namespaces de l’autoloader, c’est ici : http://framework.zend.com/manual/en/zend.loader.autoloader.html
La première chose consiste à créer ses bibliothèques personnelles, qui serviront pour le projet courant, et pour les projets à venir. J’utilise systématiquement deux namespaces pour chaque projet : le namespace de l’entreprise, et celui du projet en question. Cela permet de cloisonner les problématiques communes des besoins réellement spécifiques. Dans les exemples qui suivent, on considérera que le namespace d’entreprise est MyCompany et le namespace du projet MyProject.
Personnellement je dérive systématiquement les classes Zend_Db_Table (ainsi que les Row et Rowset) et la classe Zend_Controller_Action, même quand je n’ai rien à y mettre pour le moment. De cette manière, si jamais un traitement générique devait être décidé plus tard (par exemple passer à la vue un id Google Analytics) il serait encore possible de manoeuvrer sans remettre en cause tout notre projet. De la même manière, si on veut implémenter un algorithme maison de vérification des données avant toute sauvegarde, on sera bien content que toutes nos tables soient des classes filles de notre dérivée de Zend_Db_Table.
Prenons par exemple l’IndexController, sa classe mère sera MyProject_Controller_Action, elle même fille de MyCompany_Controller_Action, fille de Zend_Controller_Action. Un peu lourd à mettre en place en début de projet, ça devient bénin par la suite et permet une grande souplesse… On pourrait même aller plus loin, et créer un contrôleur type par module du projet si le besoin se faisait sentir.
Le reste de la bibliothèque sera beaucoup plus dépendant de vos besoins réels, mais quelques outils tels qu’un loader de formulaire ou de modèle pourrait grandement aider dans une majorité des cas… Une règle d’or toutefois : le but est bien de factoriser le maximum de code que l’on peut, mais il ne faut pas tomber dans l’excès. Certains cas par exemple semblent très facilement factorisable, mais leur évolution est quasiment impossible à prédire. Ca peut être le cas de la sauvegarde des données depuis un formulaire, ou toute demande ultérieure peut venir casser et / ou largement complexifier votre algorithme initial (qu’arrivera-t-il si on modifie l’interface pour diviser le formulaire en plusieurs pages, ou si on ajoute de nombreux éléments qui n’ont pas à être enregistrés mais qui influent sur le traitement…).
Enfin, pensez réutilisation : vous avez besoin d’une ressource supplémentaire dans votre bootstrap ? Même si celle-ci est propre au projet, tant que c’est possible privilégiez la création d’une classe de ressource plutôt que d’un élément de code « en dur » dans la classe de bootstrap. Comme ça, si le besoin s’avère plus général que prévu de prime abord, il sera toujours temps de la faire passer de MyProject vers MyCompany pour le prochain projet…
Un dernier conseil : le Zend Framework évolue vite. Aussi, si il est de bon ton de dériver les classes du Zend Framework pour leur greffer des traitements plus « personnels », faites attention à ne pas tout remettre en cause, ou vous risqueriez de passer pas mal de temps d’adaptation à la prochaine mise à jour majeure du Framework… Dans le même esprit, quand vous implémentez une ressource, un service, une conversion de mesure qui vous paraît très commune et qui pourtant est absente du Framework, n’en faites pas plus que le nécessaire. Il y a fort à parier qu’une version officielle sortira tôt ou tard, aussi contentez-vous du besoin du moment, il sera toujours temps d’utiliser la solution officielle quand elle existera. Prenons le cas de la ressource Log, sortis avec Zend Framework 1.10, et dont j’ai dû créer un ersatz cet été pour les besoins de deux projets : y passer plus longtemps pour prendre en compte plus de cas de figures aurait été inutile, vu que le manque est désormais comblé.
J’espère que ce bref article aidera quelques lecteurs à se représenter leurs futurs projets Zend Framework, ou au moins qu’il soulèvera quelques commentaires 
N. B. : Après mûre réflexion, je ne suis pas totalement persuadé de l’indispensabilité du couteau pour la poule.