Créer un projet avec Zend Studio (ZDE)

Je remercie toute l'équipe de Developpez ainsi que celle de Zend France, de leur soutien et de m'avoir donné l'occasion d'essayer ce logiciel.

L'installation se passe sans histoires. Zend Studio est développé en Java, ce qui le rend disponible pour tous les systèmes d'exploitation ayant une machine virtuelle Java.

Il est préférable d'installer la Zend Platform avec Zend Studio, si vous souhaitez profiter de ses capacités avancées de débogage. Pour pouvoir profiter de la Zend Platform en version 3, il faut avoir Zend Core 2… Pour ma part, j'ai utilisé les versions 2.0.3 de Core et 3.0.3 de Platform.

Cependant, Zend Studio est fourni avec sa propre version de PHP, qui ne correspond peut-être pas à la version de votre machine de développement, en particulier le php.ini et les extensions disponibles… Il est donc nécessaire de modifier la configuration de Zend Studio afin qu'il utilise vos extensions habituelles. Pensez à activer les mêmes extensions que dans votre php.ini :

extension_dir=C:\PHP5\ext

Il reste une petite chose à régler avant de commencer. Dans certaines versions, Zend Studio configure mal le plugin du navigateur Web. Dans mon cas par exemple, le chemin d'accès à Zend Studio était défini pour une version incorrecte de Studio, ce qui m'empêchait de lancer Studio depuis le bouton ajouté au navigateur par le plugin. Pour y remédier, il suffit d'aller dans Extra Stuff / Settings et de sélectionner le chemin adéquat :

Je vais prendre pour exemple le tutoriel de Rob AllenDébuter avec le ZF et l'utiliser comme un projet.

Voici les étapes de création d'un projet sous Zend Studio :

1. Choisir le nom ;
2. Sélectionner les répertoires à inclure ;
3. Configurer le débogueur ;
4. Configurer Java Bridge.

Et voilà, votre projet est prêt ! Zend Studio va immédiatement parcourir votre code pour lire tous les scripts, afin de compléter sa base de données interne de variables, constantes, classes et prototypes de fonctions (vous pouvez demander à Zend Studio de rafraîchir ces informations en allant dans Tools / Rebuild Inspection Data). Il se peut que votre projet fonctionne, mais que Zend Studio ne parvienne pas à trouver tous les scripts, auquel cas vous obtenez la boîte de dialogue suivante (que vous pouvez demander vous-même en allant dans Project / Check Included Files…) :

Cela n'empêche pas votre application de fonctionner, mais cela empêche peut-être Zend Studio de proposer une autocomplétion de votre code. Dans mon cas il n'en a rien été, car Studio connaît le Framework :

Une étape importante de tout projet est le déploiement en production, une fois tous les tests réussis.

Zend Studio peut se connecter à un serveur FTP en mode normal, en SFTP ou en FTP par SSH, ce qui permet au développeur de transférer ses scripts en toute confiance. De plus, le protocole FTP est intégré au gestionnaire de fichiers de Studio à tel point qu'il est possible de glisser-déposer des fichiers depuis un serveur FTP vers le système local de fichiers (et vice versa) ; il est également possible d'éditer directement les fichiers en ligne, comme s'ils étaient en local.

Pour utiliser un serveur FTP, il suffit d'aller dans le menu File / Add FTP Server et de remplir les champs habituels (nom, adresse, utilisateur et mot de passe). Il apparaît alors dans le Gestionnaire de fichiers.

Le déploiement de l'application consiste alors simplement à glisser/déposer le répertoire du projet (système local) vers le serveur FTP en utilisant le gestionnaire de fichiers interne à Zend Studio.

III-A-1. Depuis Zend Studio (touche F5)▲

Afin de résoudre facilement les erreurs, et surtout afin de ne pas risquer de créer des erreurs en résolvant des problèmes, il est préférable de ne pas modifier le code du projet avant de savoir ce qu'il se passe. Utiliser print, echo, die et exit est une bonne solution pour un projet composé de quelques scripts, mais pour un projet de plusieurs dizaines de scripts cela devient impossible à gérer : on risque d'oublier du code destiné au débogage dans un script, d'oublier que l'on a mis certaines portions de code en commentaires, etc.

Le débogage est la solution à tous ces problèmes.

Avec le débogage, vous pouvez mettre des « points d'arrêt » dans votre code et ainsi exécuter les scripts petit à petit, en faisant des pauses que vous contrôlez, et tout cela sans modifier votre code un seul instant. Vous pouvez donc étudier le comportement de vos scripts sans en modifier le contenu et sans risquer d'oublier de rétablir le code qui fonctionne.

Zend Studio propose deux manières de déboguer le code : en interne ou avec un serveur distant. Nous allons utiliser la méthode la plus simple : en local.

Plaçons des points d'arrêt avant et après la première affectation des variables $config et $registry afin de voir comment fonctionne le débogage. Placer un point d'arrêt se fait simplement en cliquant dans la marge, sur le numéro de ligne. Zend Studio colore en rouge les lignes avec point d'arrêt :

Le menu Debug / Go nous permet maintenant de voir ce qu'il se passe. Il est préférable d'afficher la Debug Window avant de commencer (image ci-dessus). Zend Studio commence le débogage et met en pause l'exécution du script à l'endroit du premier point d'arrêt. Dans la Debug Window, l'onglet Variables est maintenant rempli avec toutes les variables qui ont été affectées jusqu'ici : pour le moment, seules les variables automatiques de PHP sont présentes. Nous pouvons en examiner le contenu, ce qui est équivalent à utiliser var_dump au même endroit dans le code.

Continuons le débogage avec Debug / Go : Zend Studio fait une autre pause sur le second point d'arrêt. Une nouvelle variable est maintenant apparue dans l'onglet Variables de la Debug Window :

L'intérêt du débogage par rapport à echo/var_dump est maintenant clair : cela facilite la lecture des données tout en épargnant le code de tout type de modification inutile. Mais ce n'est pas tout, car il est également possible de modifier une valeur depuis Zend Studio, pendant la session de débogage.

Continuer le débogage nous montre que la variable $registry apparaît également dans la liste. Il est possible d'ajouter d'autres points d'arrêt avant de continuer, sans quoi la session de débogage s'arrêtera là. Positionnons le curseur de la souris après la dernière ligne de code du script :

 

Sélectionnez

$frontController->dispatch();

Le menu Debug / Go To Cursor permet d'avancer l'exécution du script jusqu'au curseur, ce qui est un bon moyen de pallier le problème des points d'arrêt (efficaces uniquement sur les lignes de code).

Nous pouvons maintenant inspecter l'ensemble des variables du script avant que le front controller lance l'exécution du reste du script. Nous pouvons notamment voir quelle action, quel module et quel contrôleur sont déterminés dans $frontController->_request, ce qui permet par exemple de diagnostiquer les problèmes de réécriture d'URL, ou bien le corps de la réponse dans $frontController->_response->_body->default, ou encore les entêtes HTTP dans $frontController->_response->_headers par exemple. Tout ceci est spécifique au Zend Framework, mais vous saisissez l'idée.

Le problème de ce type de débogage est qu'il ne prend pas en compte les paramètres que l'on peut vouloir envoyer à l'application… C'est l'environnement de Zend Studio avec son php.ini, sa configuration pour Apache, etc. C'est pour cette raison que Zend Studio propose un autre moyen de déclencher le débogage : depuis le navigateur Web.

III-A-2. Depuis le navigateur Web (plugin)▲

Zend Studio vous a proposé d'installer un plugin pour certains navigateurs Web, en particulier Internet Explorer et Firefox ont chacun le sien. Ce plugin vous permet d'initier une session de débogage depuis votre navigateur, ce qui vous permet d'analyser le comportement de vos scripts en situation réelle.

Conservons par exemple le curseur de la souris après la dernière ligne de code du script zf-tutorial/index.php et chargeons l'accueil du projet dans le navigateur. Rien ne se passe dans Zend Studio puisque nous n'avons rien demandé au plugin. Voici ce que propose le plugin de Firefox :

Si l'on demande de déboguer la page suivante, puis que l'on utilise l'un des liens de la page affichée dans le navigateur, alors Zend Studio lance une session de débogage et nous pouvons inspecter le code de la même manière que précédemment.

Profiler un script revient à étudier le temps d'exécution de chacun des appels de fonction dans chacun des scripts au cours de l'exécution globale. Le processus se lance à partir du plugin dans le navigateur.

Le profiler donne les informations sous trois formes :

• diagramme du temps d'exécution des scripts impliqués ;
• diagramme des temps d'exécution des appels de méthodes ;
• arbre hiérarchique des appels de méthodes.

Bien entendu, le temps d'exécution dépend de trop nombreux paramètres pour être une information utile. Ici par exemple, quatre secondes est un temps bien trop long pour un script aussi simple : mon ordinateur est largement fautif et il ne faut pas tenir compte de cette information. En revanche, les pourcentages ne devraient pas trop varier entre deux exécutions du script.

Le profiler est un outil fondamental pour savoir où sont les goulots d'étranglement, au long de l'exécution d'un script. Il est primordial d'apprendre à se servir d'un profiler afin d'être en mesure d'optimiser ses scripts, surtout dans le cadre d'un gros projet.

Zend Studio dispose d'un analyseur de code source. C'est un autre moyen de traquer les problèmes éventuels. C'est une fois que les scripts fonctionnent que l'analyseur entre en jeu : il permet de déceler le code inutile, par exemple suite à un changement dans une portion de code il est possible d'oublier de supprimer une autre portion de code ou une variable devenue inutile. L'analyse est là pour cela.

Dans le tutoriel de Rob Allen, il semble par exemple que la variable $rows_affected appartienne à cette catégorie de variables obsolètes (et peut donc être supprimée) :

Documenter un projet est une tâche essentielle pour permettre aux autres développeurs d'utiliser le projet ou de le reprendre. Un projet non documenté a peu de chances d'être utilisé et moins encore d'être maintenu.

Zend Studio utilise phpDocumentor pour générer une documentation automatique à partir de commentaires situés dans le code source.

Au cours du développement d'un projet, il est fréquent de modifier le code après avoir testé avec succès une fonctionnalité. Cela peut se faire au moyen de copies des dossiers, mais cette technique rend extrêmement difficile le suivi du code qui fonctionne et impossible le suivi dès lors que plusieurs développeurs participent au projet.

La meilleure solution à ce problème est un gestionnaire de versions pour code source. Les outils les plus connus à ce sujet sont CVS (le plus ancien) et SVN (plus récent et plus mature). Des solutions propriétaires ont également vu le jour, par exemple MS Visual SourceSafe.

Il faut donc disposer d'un tel gestionnaire et configurer Zend Studio pour l'utiliser avec notre projet. Voici comment se passe la configuration d'un compte SVN :

Commençons par faire un checkout, ce qui prépare le répertoire sur le disque local :

Si le checkout a fonctionné, le répertoire est préparé pour SVN. Sous Windows, il ressemble maintenant à ceci dans l'explorateur :

Nous pouvons désormais utiliser Zend Studio pour mettre le repository à jour. Il faut d'abord ajouter (add) un à un les répertoires pour lesquels nous voulons contrôler les versions. Dans notre cas, nous allons tout contrôler excepté le Framework (sous le dossier « library »).

Ajouter les fichiers et dossiers permet à SVN de savoir ce qu'il doit contrôler. Il ne reste plus qu'à effectuer un commit pour envoyer tous les fichiers contrôlés vers le serveur SVN :

Zend Studio vous permet d'explorer vos bases de données et d'exécuter des requêtes depuis l'EDI. Cela vous épargne de devoir installer un outil externe si vous souhaitez effectuer des requêtes directement sur votre base de données, ce qui peut être utile pour le débogage.

Zend Studio peut générer pour vous les fichiers WSDL de vos services Web.

Zend Studio est un excellent environnement de développement intégré. Il est très robuste, de très nombreux outils permettent de faciliter la navigation dans le code source, la prévention et la résolution des problèmes.

S'il faut lui trouver un défaut, ce sera probablement l'impossibilité de drag-and-drop de scripts depuis le système d'exploitation vers l'EDI, ou bien le peu d'informations fournies lors du déploiement de l'application (pas de barre de progression).

• FAQ Zend Studio.
• FAQ, tutoriels et forum Zend Framework.
• Forum d'entraide sur Zend Studio.