Au niveau programmation, je ne savais trop où me situer.
En effet, si la perspective d’avoir moins à coder en utilisant des frameworks tels Symfony, Copix ou encore Jelix me plaisait, je n’aime pas ne pas avoir le contrôle complet sur le développement d’une application. L’impression que me laissent ce genre de framework est de générer un squelette assez rigide, personnalisable a posteriori. A l’inverse, recoder soi-même tout, à chaque application, c’est exténuant et même si l’on sait exactement comment le tout fonctionne, c’est une grosse perte de temps.
Jusqu’à il y a peu, je me contentais de suivre une approche « plus ou moins » MVC, en séparant bien les choses, et en utilisant des librairies existantes (comme Smarty ou Adodb – Oui, j’utilisais adodb, car PearDB me semblait peu pratique, vraiment pas performant, et accessoirement mal codé). Et puis à force de faire joujou avec une bonne part des frameworks (surtout symfony, copix et le framework Zend), j’ai appris à connaitre ces trois là en particulier, et c’est il y a très peu de temps que j’ai vraiment craqué pour le framework Zend.
Si à première vue ZF fait décousu par rapport aux autres, il est également beaucoup plus souple, on se sent plus libre d’organiser notre application web comme on le souhaite, tout en bénéficiant de nombreuses classes simplifiant beaucoup de choses (la gestion de la BDD, les sessions, les ACL, des locales, de la traduction …). Seul bémol, il faut batailler un peu avec Zend_View_Interface pour pouvoir utiliser Smarty à la place de l’outil de base (qui est bêtement … PHP).
Mais au final c’est peu de choses et même s’il y a autant voir plus de notions à comprendre que dans d’autres frameworks, même si l’on gagne un peu moins de temps lors des premiers développements, les suivants réutilisent la même base, et chacune des classes peut s’utiliser indépendamment, l’architecture MVC étant gérée par la classe Zend_Controller et quelques autres (alors que les petits contrôleurs sont gérés par une instance de classe Zend_Controller), et l’on peut choisir une autre architecture dès le moment où l’on ne charge pas cette classe.
Dans la plupart des cas, on se crée donc un fichier d’initialisation de l’application, où l’on charge les classes du Framework que l’on souhaite utiliser, mais après, c’est complètement libre. Il y a plus de code à faire soi-même, c’est certain, mais on peut vraiment choisir une architecture qui nous est propre.
Petit conseil, installez Xdebug, pour avoir les erreurs présentées de manière chronologique et détaillée.
Important : Ce billet n’est pas sponsorisé ou quoique ce soit ! Ce n’est que mon avis, ce que je pense, et vous êtes libres d’adorer Django, RoR, ou votre framework maison !
(Ne soyez pas aussi étonné que cet être féérique)
PS : Loin de moi l’idée de dénigrer la qualité de frameworks tels que symfony, copix, jelix, et d’autres, mais ils ne correspondent pas à ma façon de programmer, par le simple fait qu’ils automatisent tout, ajouté à d’autres détails comme la multitude de fichiers de configuration de copix, la pléthore de modules de Copix …
Si vous aimez un de ces frameworks, c’est qu’il répond à votre besoin et donc mes propos ne vous concernent pas.
PS 2 : Une classe Outil pour créer automatiquement de nouveaux projets avec le Zend Framework est apparue il y a peu, le nom du bébé est Zend_Tool (en Anglais). Il permet même d’ailleurs la création de contrôleurs et même d’actions, en créant les vues associées.
