Maintenant que vous vous êtes familiarisé avec Zend Framework, il est temps d'arrêter de naviguer en vue de la côte, et d'attaquer les grands fonds. Ne vous inquiétez pas, nous allons vous permettre de rester à flots, pour l'instant.

Le sujet de la seconde partie de ce livre est l'écriture d'une application de blog. La raison pour laquelle j'ai choisi un Blog est parce que c'est une application qui est extrêmement familière, pour la plupart d'entre nous. En éliminant les incertitudes au sujet de ce qui est développé, nous pouvons mieux nous concentrer sur l'implémentation des fonctionnalités que nous connaissons bien. Néanmoins, sauter au milieu d'un projet avec les yeux bandés n'est pas une bonne idée. Je voulais un petit blog perso que j'aie construit moi-même (je trouve ces trucs amusant) depuis un moment, donc, allons-y !

Pour planifier notre petit projet, nous devons commencer par nous poser la question la plus évidente qui soit : quel est l'objectif du projet ?

J'aime que mes objectifs soient court et clairement définis. Si c'est évident, tant mieux. Le premier objectif est que nous nous souvenions de pourquoi nous faisons cela, et de poser un cadre aux futures discussions à propos de fonctionnalités.

Même si un objectif court et clair vous permet d'être concentré sur ce que vous souhaitez obtenir à la fin de la journée, il nous faut tout de même ajouter quelques détails, afin que nous sachions où commencer. Plutôt que de nous perdre dans un long document de spécifications, nous n'avons besoin que de quelques lignes un peu plus détaillées, définissant comment l'application fonctionnera.

Arrivés ici, nous avons suffisament d'informations pour que les choses soient intéressantes. Nous pourrions continuer à allonger cette liste jusqu'à ce qu'elle fasse plusieurs pages de long, mais ces quelques points reprennent les principales fonctionnalités qui correspondent à notre objectif de départ.

Considérant notre liste de fonctionnalités requises, illustrée sous forme de simples phrases indiquant ce que les utilisateurs peuvent faire, nous pouvons commencer à identifier les principaux blocs de notre application. Puisque nous utilisons Zend Framework, nous pouvons prendre quelques raccourcis, et nous concentrer sur ce qui est vraiment important : les besoins spécifiques de l'application. C'est là que nous devons nous tourner vers la Modélisation de Domaine. Pour faire simple, nous pouvons commencer à idenditifier les entités de notre système, et les données qui leur sont associées.

Notez qu'au point où nous en sommes, il est important de réaliser que nous ne réfléchissons pas en termes de base de données. Les Bases de Données sont un outil qui permet à un Modèle d'être stocké entre les requêtes, mais, à cette étape, nous ne sommes pas encore en train de concevoir des tables ou d'écrire du SQL. Nous verrons cela au prochain chapitre, lorsque nous entrerons plus en détails dans la question du comment implémenter le Modèle.

Les entitiés que nous pourrions identifier (et qui pourraient devenir nos objets de domaine dans le futur) incluent :

Nous pourrions éventuellement éliminer l'entité Lecteur / Reader, puisque, dans notre application, un Lecteur est un utilisateur anonyme. La seule chose que nous pourrions vouloir conserver pour les utilisateurs anonyme serait des données de session. cela dit, encore une fois, alors que l'utilisation d'une base de données est optionnelle dans un Modèle, peut-être qu'avoir un objet Reader pour encapsuler les données de session d'un utilisateur anonyme n'est pas une mauvaise idée : après tout, où est-ce que nous pourrions gérer cela ? Dans le Contrôleur ? Comme nous l'avons vu dans un chapitre précédent, le Contrôleur n'est PAS le Modèle.

Les trois autres sont des candidats évidents. Nous pouvons détailler ces entités candidates pour déterminer ce dont elles auraient, au minimum, besoin. Notons que lorsque nous traitons du Modèle, je considère que toutes les entités seront des objets, donc il n'y a pas de référence à des clefs étrangères (c'est un point qui est du ressort de la base de données) puisque chaque objet peut contenir un autre object en faisant référence à n'importe quelle entité liée ou proche.

Il y a probablement plein d'autres choses que nous pourrions ajouter, mais elles ne sont pas importantes pour l'instant. Nous n'avons besoin de voir que des données de base, et comment elles pourraient être reliées à d'autres Modèles dans notre domaine.

Pour terminer cette analyse initiale, nous pourrions jeter un coup d'oeil aux types de "pages" que notre application devra générer. C'est une tâche qui peut être difficile, en fonction de la manière dont nous définissons le terme de "page". Devons-nous inclure les pages ou les URLs qui ne répondent qu'à des requêtes Ajax ? Qu'en est-il pour les API de Web Services, comme une future implémentation du protocol AtomPub, pour pouvoir blogger en dehors de notre application ? Encore une fois, si nous ne sommes pas certain à propos de quelque chose, nous le reportons à plus tard. Donc, les principales pages dont nous sommes sûrs peuvent inclure :

Maintenant, nous avons au moins une idée de ce qu'il nous faut mettre en place. Sans plus être aveugle ni en train de regarder dans le vide devant notre IDE, nous pouvons nous installer et commencer à coder. Au prochain chapitre, nous commencerons par préparer notre Modèle. Ensuite, nous pourrons travailler à la présentation de l'application.

Toute application de blogging va venir avec son lot de fonctionnalités, et nous pourrions être tentés de rajouter des points aux spécifications de notre nouvelle application. Cela apporterait des problèmes, puisque a) nous diviserions notre attention, b) nous tenterions de prédire des besoins qui ne sont pas confirmés, et c) des spécifications supplémentaires sont inutiles avant que le coeur de l'application de Blog ne commence à apparaitre. Donc, nous développerons le Blog de manière incrémentale, en assignant les fonctionnalités requises à des itérations que nous compléterons sous forme d'étapes distinctes et mesurées, tout en s'assurant tout au long du processus que l'application soit stable et unitairement testées avant de commencer une autre itération.

Cela va de paire avec une autre notion du monde de l'eXtreme Programming, "You Ain't Gonna Need It" (or YAGNI - Vous n'en n'aurez pas besoin). YAGNI enseigne que trop réfléchir à des fonctionnalités qui ne sont actuellement pas nécessaire a un certain nombre de sérieux inconvénients. Tout d'abord, vous y passez du temps, ce qui signifie soit que vous avez trop de développeurs (je n'ai jamais dit ça !), soit que vous avez des développeurs qui passent du temps sur des fonctionnalités futures, plutôt que sur des fonctionnalités actuellement nécessaires. Ce temps pourrait être passé en développement, tests, analyse de besoins, documentation, etc. Tout ça pour quelque chose dont nous n'avons pas besoin maintenant. Ensuite, nous ne tenons pas compte du fait que le futur est incertain. Qu'est-ce qu'il se passera s'il s'avère que nous n'aurons jamais besoin de la future fonctionnalité en question ? Et si un client change d'avis à propos de quelque chose de plus basique, et rend un lot de ces futures fonctionnalités redondantes ? Et si implémenter la future fonctionnalité empèche une autre fonctionnalité, dont nous ne nous rendons compte de la nécessité que plus tard, d'être ajoutée ? En d'autres termes, ajouter la nouvelle fonctionnalité requiert plus de travail pour l'implémenter, et peut même signifier devoir ajouter encore d'autres fonctionnalités actuellement non nécessaires pour supporter quoi que ce soit que nous sommes en train d'implémenter.

Le développement incrémental fonctionne ici parce que je suis le client (d'aucun diraient qu'être son propre client est la pire situation possible). Cela dit, beaucoup de projets auront d'autres personnes comme client, et leurs besoins peuvent évoluer de manière conséquence au fur et à mesure que le temps passe. Le développement incrémental est un excellent procédé, mais il implique toujours d'écrire une application avant que ses besoins ne soient complètement identifiés, connus, et documentés. Tous les clients ne seront pas capable, ou ne souhaiteront pas, travailler avec un processus incertain tel que celui-ci, ou trouveront difficile de travailler en étroite collaboration avec vous de manière à ce que cela fonctionne. Un autre effet du développement incrémental est que nous devons faire attention à l'atomicité de nos tests unitaires. Une erreur courante est d'essayer d'en tester trop, en enchainant assertion après assertion dans un seul test. Dans un scénario bien délimité, cela ne fait pas grand mal, mais une fois que cela s'étend aux vues de pages et au workflow, nous pouvons nous retrouver en train de constamment éditer nos tests pour qu'ils correspondent aux besoins actuels. Editer de vieux tests n'est pas un bon signe : c'est un signal qui indique qu'ils n'étaient pas assez précis au départ.

Ce processus est largement adapté pour notre blog. C'est une application simple, pour laquelle nous pouvons accepter de gérer les nouveaux besoins au fur et à mesure de leur apparition, dans les futurs chapitres.

Même s'il serait bien de tout faire avec Zend Framework, la vérité est que nous aurons besoin, de temps en temps, d'autres outils supplémentaires. Puisque je suis un grand amateur de jQuery qui n'a pas la moindre connaissance à propos de Dojo, vous devriez garder la version la plus récente de jQuery sous la main quand nous commencerons à jouer avec des requêtes Ajax et de la manipulation d'interface utilisateur. J'utiliserai aussi le Framework CSS Blueprint pour conserver mes éditions de CSS au strict minimum, et conserver une structure de page simple sans avoir à me battre pendant des heures avec la mise en place de grilles. Une autre chose dont je ne me passe que rarement est une bonne bibliothèque de filtrage HTML, qui est quelque chose que Zend Framework ne fourni actuellement pas. J'utiliserai HTMLPurifier 4.0.0 pour cela. Enfin, mais ce n'est pas le point le moins important, j'utiliserai PHPUnit pour tous les tests unitaires, donc assurez-vous de l'avoir installé depuis le channel PEAR PHPUnit.

J'en dirai plus, notamment au sujet de leurs procédures d'installation, lorsque nous aurons besoin de ces outils.

Ceci était un chapitre très court, et je concluerai en rappelant l'introduction du livre. Puisque l'objectif de ce livre est d'aider ceux qui se trouvent dans les "grands fonds", je me permet de supposer que vous avez une certaine familiarité avec Zend Framework. Je suppose aussi que vous êtes capable de lire le Guide de Référence indépendamment de ce livre, et, donc, ne passerai pas une importante quantité de temps sur chaque composant que nous rencontrerons, à moins qu'il ne soit utilisé fréquemment. Un exemple est Zend_Db, qui a une entrée impressionnante dans le Guide de Référence, détaillant son API, des exemples, et les méthodes utiles. Plutôt que de passer un chapitre entiter (ou cinq) pour expliquer Zend_Db et les classes le composant, le prochain chapitre est bien plus intéressé par la mise en évidence de l'utilisation de Zend_Db pour créer un Modèle. Notre Modèle ne requiert même pas beaucoup de connaissances de Zend_Db pour que vous puissiez le suivre.

Si vous avez besoin de certains détails spécifiques de Zend_Db, référez-vous au Guide de Référence. Eventuellement, j'ajouterai de nouveaux chapitres/annexes au livre si c'est nécessaire, mais il n'y a pas grand chose que je puisse vous offrir qui aille au-delà de ce que le Guide de Référence vous apporte déjà (Il est bien détaillé et très clair).

Il devrait aussi être évident que ceci ne va pas être un simple tutorial de blog. Les exemples en rapport avec le Framework de développement d'application Web sont mélés avec ceux du simple blog, mais le tout est orienté vers une application plus complète, qui aura besoin de faire un usage plus intense des composants de Zend Framework.