Structurer ses développements PHP avec Zend Framework (Partie 1/2)

#framework#php#zend

Face à JavaEE ou .Net, PHP peine à s’imposer dans le milieu professionnel. Les raisons sont multiples, mais certains outils lui permettent cependant aujourd’hui de s’y faire une place. C’est le cas de certains frameworks tels que Symfony ou Zend Framework qui permettent de structurer et d’industrialiser les développements et apportent ainsi au langage une meilleure visibilité au sein des entreprises. Cet article propose une première approche de Zend Framework.

Présentation de Zend Framework

Zend Framework est un framework pour PHP 5 développé par Zend Technologies et distribué sous licence BSD. Il permet de structurer les développements en PHP tout en mettant en avant les bonnes pratiques du développement orienté objet. Complet et bien documenté, il offre toutes les briques nécessaires à la réalisation d’applications professionnelles. Les différents composants du framework sont suffisamment dissociables pour ne pas être obligé de baser toute l’architecture de l’application sur Zend Framework.

La version 2 du framework, pour laquelle la compatibilité ascendante n’est pas assurée, est en cours de développement. Nous en sommes à la cinquième version beta, dernière de la série des beta planifiées, mais il est préférable de continuer à utiliser la dernière version stable de la branche 1.x pour tout projet ayant une mise en production planifiée. En effet, à court terme, la date de sortie de la version finale et stable de Zend Framework 2.0 n’est pas encore déterminée.

Dans cet article, nous nous appuyons sur un exemple simple pour aiguiller un nouvel utilisateur dans l’apprentissage de ce Framework. L’objectif est de mettre en place un environnement de développement et de se familiariser avec Zend Framework en réalisant une première page et un premier formulaire au sein d’une application MVC. Il ne nous est pas ici possible de rentrer dans les détails du fonctionnement des différents composants mis en œuvre, certaines explications sont passées sous silence par souci de concision.

Présentation de l’application exemple

L’exemple présenté ici est avant tout destiné à proposer une première expérience simple avec Zend Framework. Il s’agit d’une interface permettant à différents participants de se mettre d’accord sur un lieu où aller prendre le déjeuner en utilisant la méthode du vote par assentiment : chaque utilisateur sélectionne un ou plusieurs restaurants / lieux où il souhaite déjeuner, celui remportant le plus de voix étant naturellement choisi. Il s’agit là d’une question épineuse que nous avons régulièrement à résoudre au bureau entre collègues !

Cette petite application utilise l’implémentation du patron d’architecture MVC (Modèle-Vue-Contrôleur) proposée par Zend Framework. Elle consiste en une simple page de présentation du résultat des votes du jour ainsi qu’une page de formulaire pour voter. Elle permet de présenter l’outil en ligne de commande fourni avec le framework, couteau suisse du développeur utilisant Zend Framework, ainsi que certains des principaux composants.

Environnement de développement

L’exemple présenté ici a été testé dans l’environnement suivant :

  • Apache avec « mod_rewrite » activé et acceptant les fichiers « .htaccess »
  • PHP version 5.3.6 (5.2.4 minimum pour faire fonctionner Zend Framework version 1.11.11)
  • Zend Framework version 1.11.11

Côté base de données, nous utilisons ici SQLite qui permet d’éviter l’installation et la configuration d’un SGBD, mais Zend Framework peut être utilisé avec les SGBD les plus connus.

Installation du framework

Tout d’abord, il faut récupérer l’archive « Zend Framework 1.11.11 Full » sur la page de téléchargement du site de l’éditeur : « http://framework.zend.com/download/current/ ».

L’installation du framework ne pose pas de problème particulier. Il s’agit principalement d’une bibliothèque PHP qui doit être désarchivée et « visible » par l’application. Il faut donc l’ajouter au projet PHP un fois celui-ci créé, ou l’ajouter dans l’« include path » dans le fichier de configuration « php.ini ». Pour simplifier le développement, Zend Framework est livré avec un outil en ligne de commande, situé dans le répertoire « bin » de l’archive, permettant d’exécuter automatiquement un certain nombre de traitements. Très pratique en environnement de développement, il n’est par contre pas indispensable au fonctionnement de l’application.

L’outil en ligne de commande nécessite un peu de configuration pour être reconnu comme commande intégrée afin de ne pas devoir préciser, à chaque utilisation, le chemin complet. Sous les systèmes de type Unix (Linux ou OSX notamment), cela peut être fait en ajoutant l’alias suivant au fichier « .bash_profile » du répertoire utilisateur :

où « chemin/vers/ZendFramework » est le répertoire où est décompressée l’archive Zend Framework.

Pour vérifier que l’alias est bien effectif, il suffit de lancer la commande zf pour lui demander, par exemple, la version de Zend Framework :

qui devrait retourner (au numéro de version près) :

Le pendant Windows existe sous la forme du script « bin/zf.bat » dont on pourra ajouter le chemin dans la variable d’environnement PATH.

Création et configuration du projet

Lors de la réalisation d’un nouveau projet MVC avec Zend Framework, la première étape consiste à créer l’arborescence du projet et les fichiers principaux. L’outil en ligne de commande permet de générer une arborescence de projet par défaut. Pour cela, on se place dans le répertoire désiré pour le développement de l’application et on utilise la commande suivante qui prend en paramètre le nom du projet :

Cette commande crée un répertoire « VoteForLunch » qui contient l’arborescence représentée en Figure 1. Les fichiers générés contiennent le squelette des différentes classes de base.


Figure 1 : arborescence par défaut d’une application MVC Zend Framework (CLIQUER sur l’image pour l’agrandir)

Toutes les lignes de commande présentées par la suite sont à exécuter depuis le répertoire racine de l’application qui vient d’être générée : « VoteForLunch/ ».

Dans ce répertoire nouvellement créé, nous pouvons noter l’existence par défaut d’un répertoire consacré à MVC, nommé « application ». Il contient lui-même un répertoire pour les contrôleurs, un répertoire pour les vues, ainsi qu’un répertoire pour les modèles. Cette application MVC fait usage notamment des composants « Zend_Application », « Zend_Controller » et « Zend_View » du framework.

L’application peut se paramétrer en grande partie par son fichier de configuration « application/configs/application.ini » découpé en différentes sections correspondant aux différents environnements (« [développement] », « [test] », « [production] ») de l’application, ainsi que par sa classe d’amorçage ou « Bootstrap » (fichier « application/Bootstrap.php ») qui comme son nom l’indique contient tout ce qui est nécessaire à l’initialisation de l’application.

Remarque : le composant « Zend_Application » fait également usage d’un « autoloader » qui permet de faire automatiquement le lien entre une classe et le chemin vers le fichier dans lequel cette dernière est définie en se basant sur des conventions de nommage. Nous n’avons pas besoin d’en maîtriser ici le fonctionnement exact, car nous utilisons l’outil en ligne de commande qui respecte ces conventions. Cependant, il est important d’en connaître l’existence pour aller plus loin avec le framework.

Le répertoire « public » est le répertoire de l’application web qui doit donc être lisible par le serveur web. Il contient le fichier « index.php » qui conjointement au fichier « .htaccess », qui lui redirige toutes les requêtes, remplit le rôle de contrôleur frontal (Front Controller ). Le répertoire « docs » est destiné à recueillir la documentation relative à l’application. Le répertoire « tests » contient les tests unitaires du projet mais nous n’en parlons pas dans cette prise en main. Enfin, le répertoire « library » contient, comme son nom l’indique, toutes les bibliothèques nécessaires à l’exécution de l’application. Vide par défaut, nous allons y ajouter la bibliothèque de Zend Framework précédemment désarchivée. Pour ce faire, nous créons un lien symbolique (pour les systèmes Unix) de la façon suivante :

Il est également possible de simplement copier la bibliothèque dans le répertoire « library ». Le lien symbolique permet l’utilisation de la même version de Zend Framework dans plusieurs projets distincts.

A ce stade, le projet est opérationnel et l’application par défaut peut être lancée. Il nous reste cependant à configurer le serveur web de développement. Nous supposons ici que le serveur de développement se trouve sur la machine de développement. Le site web se trouve dans « VoteForLunch/public ». Il est possible de configurer un hôte virtuel sous Apache comme spécifié dans le fichier « docs/README.txt », ou simplement de le configurer pour qu’il utilise le répertoire « public » de cette application comme répertoire web par défaut. De cette façon, l’accès au projet se fait très simplement par l’URL « http://localhost/ ».

Remarque : une application MVC Zend Framework utilise le patron de conception (design pattern) « Front Controller ». Toutes les requêtes sont routées au travers de la même page « index.php ». Le contrôleur frontal est en charge d’aiguiller les demandes vers les bons contrôleurs d’actions. Les URL se forment de la façon suivante : « http://localhost/controller/action/parameters ». Lorsqu’aucun contrôleur n’est précisé, c’est l’ « IndexController » qui est appelé. Lorsqu’un contrôleur est demandé sans préciser d’action, c’est l’action index du contrôleur donné qui est appelée.

Il est important, en environnement de production particulièrement, de ne pas exposer toute l’arborescence du projet dans le serveur web. Seul le répertoire « public » doit être visible, pour des raisons évidentes de sécurité.


Figure 2 : page d’accueil par défaut d’une application Zend Framework (CLIQUER sur l’image pour l’agrandir)

Si le serveur est correctement configuré, en saisissant l’URL dans le navigateur, on obtient la page d’accueil par défaut présentée en Figure 2.

On peut configurer l’environnement d’exécution de l’application (par défaut « [production] ») en renseignant la variable d’environnement « APPLICATION_ENV ». Ceci peut se faire dans le fichier « public/.htaccess » en y ajoutant cette ligne :

ou directement dans la configuration du « VHost » comme indiqué dans le fichier « docs/README.txt ».

L’application est maintenant prête à recevoir ses premières pages !

Modèles et base de données

La première étape avant la réalisation de la première page en elle même est la création d’une base de données avec une table simple permettant de recueillir les différents votes des utilisateurs. Pour créer la base de données (un simple fichier dans le cas de SQLite), le client en ligne de commande sqlite3 suffit amplement. Il existe également des clients graphiques pour SQLite. Il est enfin possible de réaliser un script PHP chargé de la génération de la base de données suivant le type d’environnements (production, développement, test, etc.) en fonction de la configuration que nous allons préciser ci-dessous dans application.ini. Dans notre cas, nous créons la base de données « voteforlunch.db » dans le répertoire « data » avec l’outil en ligne de commande :

Une fois l’outil lancé, nous créons la table avec la commande SQL suivante :

Remarque : afin de simplifier l’exemple, nous ne créons pas ici les tables « restaurant » et « utilisateur » avec jointures vers ces tables depuis la table « vote ».

Et nous y insérons ces lignes de test :

La commande SQL :

doit alors retourner (à la date près) :

On peut alors quitter sqlite3 ce qui se fait avec la commande

Une fois la base de données créée, il faut indiquer à l’application comment l’utiliser. Pour cela on peut compléter le fichier de configuration « application/configs/application.ini » ou utiliser l’outil en ligne de commande qui peut le faire pour nous :

Cette commande permet d’ajouter la configuration de la base de données à la section « production » du fichier de configuration. Par défaut, les différentes sections héritent en premier lieu de la section « production », mais il est possible de surcharger les éléments qui diffèrent. On pourrait donc configurer l’utilisation d’une base de données spécifique à l’environnement de développement avec une commande ressemblant à ceci :

Pour cet exemple, nous nous contentons d’utiliser la même base de données pour les différents environnements. Le fichier « application.ini » doit comporter deux nouvelles lignes dans la section « [production] » :

Avec cette configuration, l’application est en mesure de se connecter à la base de données. Il reste alors à créer une source de données utilisant cette base de données. Nous utilisons pour cela le patron de conception Table Data Gateway dont l’implémentation proposée par le Framework est le composant « Zend_Db_Table » qui fait partie du composant « Zend_Db », ainsi qu’un autre patron de conception, le Data Mapper , pour l’interconnexion entre la source de données et le modèle.

Le Table Data Gateway est généré grâce à la ligne de commande :

qui permet de générer un nouveau fichier dans le répertoire nouvellement créé « application/models/DbTable » : « Vote.php ». Ce fichier est très simple, et le restera :

Très peu de paramètres sont nécessaires, « Zend_Db_Table » utilisant la définition de la table pour fonctionner (notamment la clé primaire). Il est cependant possible de configurer manuellement un certain nombre de paramètres, comme stipulé dans la documentation.

Créons maintenant le Data Mapper en charge de la liaison entre « Zend_Db_Table » et le modèle.

Le fichier « application/models/VoteMapper.php » est créé. Il contient le squelette de la classe « Application_Model_VoteMapper » que l’on complète de la façon suivante :

Remarque : des fonctions classiques du « Data Mapper », telles que « find » (qui prend en paramètre un identifiant permettant de filtrer sur la clé primaire de la table), sont ici volontairement omises, par soucis de clarté, car elles ne sont pas utilisées.

La classe de modèle en elle-même peut maintenant être créée :

Ceci génère le fichier « application/models/Vote.php ». On le complète de façon notamment à simplifier l’affectation de valeurs aux champs de l’objet « vote » à l’aide de la fonction « setOptions » qui prend un tableau en paramètre :

Nous nous intéresserons dans la seconde partie de cet article au traitement des données et à leur restitution, tâches attribuées au contrôleur et à la vue.

Il est possible de retrouver l’intégralité de cet article dans le numéro 152 du mois de Mai 2012 du magazine « Programmez ».