Test de Zend Framework
Ceux d'entre vous qui me connaissent savent certainement que je maintiens un petit framework PHP tout simple (Movicon), et donc je teste régulièrement la "compétition" pour voir quelles idées piquer où ils en sont. J'ai donc déjà testé CodeIgniter, Symfony, Yii, CakePHP et une paire d'autre, mais je n'ai pour le moment pas essayé Zend, pourtant connu. Zend est un cadre applicatif (framework) pour PHP qui a été programmé par deux des développeurs principaux de PHP. Il est très apprécié dans le milieu professionnel, et a une bonne réputation.
Notez que mon avis est forcément orienté, mais j'essaierais néanmoins de rester objectif. Notez aussi que j'utilise la version stable ici (1.1) plutôt que la version 2 qui est disponible en bêta.
D'abord, Zend est gros. C'est de loin le framework le plus massif que j'ai testé, avec une taille de 69Mo une fois décompressé.
Comme beaucoup d'autres, il propose de gérer son développement à l'aide d'un script en ligne de commande. On peut donc facilement créer tout un projet et son arborescence à l'aide d'une simple commande. Concernant la structure des applications, on notera que le point d'entrée est dans un sous-dossier public qui donc ne permet pas aux visiteurs d'accéder à autre chose, même sur un serveur HTTP mal configuré.
On peut utiliser plusieurs profils d'exécution, chacun ayant ses propres réglages, ce qui est très pratique pour déployer simplement ses applications sans s'inquiéter d'oublier du code de débuggage, ou d'utiliser la mauvaise base de donnée. Néanmoins, les fichiers de configuration sont assez peu lisible et le format des options est bizarre et difficile à retenir.
Exemple de configuration:
[production]
phpSettings.display_startup_errors = 0
phpSettings.display_errors = 0
includePaths.library = APPLICATION_PATH "/../library"
bootstrap.path = APPLICATION_PATH "/Bootstrap.php"
bootstrap.class = "Bootstrap"
appnamespace = "Application"
resources.frontController.controllerDirectory = APPLICATION_PATH "/controllers"
resources.frontController.params.displayExceptions = 0
resources.layout.layoutPath = APPLICATION_PATH "/layouts/scripts/"
resources.view[] =
resources.db.adapter = "PDO_SQLITE"
resources.db.params.dbname = APPLICATION_PATH "/../data/db/guestbook.db"
[staging : production]
[testing : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1
resources.db.adapter = "PDO_SQLITE"
resources.db.params.dbname = APPLICATION_PATH "/../data/db/guestbook-testing.db"
[development : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1
resources.frontController.params.displayExceptions = 1
resources.db.adapter = "PDO_SQLITE"
resources.db.params.dbname = APPLICATION_PATH "/../data/db/guestbook-dev.db"
On notera aussi l'utilisation proéminente de CamelCase. C'est une notion très subjective, mais beaucoup de développeurs (dont moi) trouvent ce format peu pratique ; et dans le cas d'un fichier de configuration (qui se doit d'être très lisibles), utiliser le CamelCase est abusif.
Au niveau des applications elles-mêmes, Zend associe l'URL aux contrôleurs et leurs méthodes selon la méthode segmentée classique:
http://hôte/contrôleur/méthode
Chaque méthode d'un contrôleur ne dispose que d'une seule vue (il est certainement possible de modifier ce comportement mais je n'ai pas cherché), on peut en outre définir des gabarits à l'intérieur desquels les vues sont intégrées. Ce processus peut se faire de deux différentes méthodes, ou bien en deux étapes: la vue est rendue puis inclue dans le gabarit, ou bien en plusieurs, en ayant une vue différente pour chaque partie de la page, le tout assemblé dans une seule page.
Zend utilise une forme d'ORM, mais qui est beaucoup moins impressionnant que dans Symfony et les autres. Ici on crée une classe qui représente les données à stocker, et on crée une autre classe dont le nom est dérivé et qui contient les fonctions pour sauver etc. (voir les prototypes ci-dessous) c'est assez simple, mais ça ne gère pas la création du schéma et finalement n'aide pas tant que ça. Notez que je n'ai pas pu aller plus loin car cette partie du tutorial n'a pas fonctionné sur mon installation.
class Application_Model_Guestbook
{
protected $_comment;
protected $_created;
protected $_email;
protected $_id;
public function __set($name, $value);
public function __get($name);
public function setComment($text);
public function getComment();
public function setEmail($email);
public function getEmail();
public function setCreated($ts);
public function getCreated();
public function setId($id);
public function getId();
}
class Application_Model_GuestbookMapper
{
public function save(Application_Model_Guestbook $guestbook);
public function find($id);
public function fetchAll();
}
Zend a aussi des outils pour faire des formulaires et je suis sûr qu'il regorge de trésors cachés, mais il m'a semblé déjà moins attractif que ses concurrents. Malgré la brièveté de mon test, je peux déjà estimer qu'il s'agit d'un outil robuste et flexible, mais d'une complexité intimidante et assez spartiate au premier usage, en particulier sur les modèles.
