Chapitre 1. Introduction

Table des matières

1.1. Zend Framework
1.2. A propos de ce livre
1.2.1. Obtenir le Code Source pour les Chapitres
1.3. Moi, Moi, Moi !
1.4. A propos de cette traduction
1.5. Vous, Vous, Vous !

1.1. Zend Framework

Dès sa sortie, le Zend Framework a pris la communauté PHP par surprise. Sa vision de toute l'approche orientée Framework est quasiment unique, dans un environnement qui a plus tendance à mettre en avant des solutions restrictives, et fortement intégrées, pour répondre aux principaux types de problèmes posés par les applications Web. Jusqu'à présent, l'approche choisie par ZF s'est révélée payante : elle a rencontré le succès auprès des programmeurs PHP.

Le Zend Framework a été conçu de manière à rendre le développement d'applications Web à la fois plus simple et plus rapide. Il accomplit la plupart de ses objectifs en vous présentant un code source écrit par des dizaines de développeurs, et testé unitairement jusqu'à plus soif. En vous reposant sur cette brique, il ne vous est plus nécessaire, en tant que développeur, d'investir à nouveau de l'énergie dans la mise en place des composants de base communs à toute application. Finalement, cela vous permet de vous concentrer sur ce que votre application doit faire, et non plus sur les fonctionnalités qu'un Framework doit, ou devrait, fournir.

C'est une manière extrêmement simpliste de penser au rôle d'un Framework, mais elle suffit : avec les années qui passent, les développeurs reconnaissent qu'ils ont passé énormément de temps à re-développer les mêmes fonctionnalités de base à chaque fois qu'ils commençaient un nouveau projet. Et c'est une histoire qui doit sembler familière à n'importe quel développeur PHP, amateur comme professionnel ; et c'est tout aussi frustrant aujourd'hui qu'au cours des années passées.

Heureusement, les développeurs frustrés par cette perte de temps ont tendance à être motivés pour arranger les choses. Ainsi, au fur et à mesure des années, les développeurs PHP ont développés toute une série de bibliothèques, de classes, d'extensions C... Et même de simples fichiers texte regroupant quantité de portions de codes utiles. Un Framework conçu pour développer des applications va plus loin que tout cela : on pourrait presque dire que c'est une application "condensée", dont tout le code source spécifique à un projet aurait été supprimé. Un Framework est portable, standardisé, fortement testé, et proposé à toute la communauté, pour être ré-utilisé à l'infini.

Choisir un Framework parmi les différentes possiblités qui s'offrent à vous, en particulier de nos jours, où passer d'un langage de programmation à un autre (et/ou d'un Framework à un autre) est à peu de chose près parfaitement acceptable, et raisonnablement commun, n'est pas tâche aisée. A peu de chose près, chaque Framework conçu pour le Web vous promettra un développement plus simple, plus aisé, plus rapide... Mais un grand nombre d'autres facteurs doivent être pris en compte ! Pour n'en citer que quelques-uns : maintenabilité, adaptabilité, facilité de mise en place de tests (automatisés !), support technique et communauté, qualité de la documentation, fréquence de mises à jour et de corrections de bugs, contrôle qualité, performances de base, courbe d'apprentissage, fonctionnalités, innovation, compatibilité avec les offres d'hébergements, respect des bonnes pratiques actuelles, mise à disposition d'informations par la communauté, ... Et c'est loin d'être une liste exhaustive ! Chaque type de programmeur aura tendance à ajouter d'autre facteurs à prendre en compte, qui seront pour certains bien plus spécifiques que ces quelques catégories et exemples.

Zend Framework s'en sort bien dans sur bon nombre de ces critères ; mais certainement pas sur tous. En fait, aucun Framework ne s'en tire bien sur tous ! Choisir un Framework reviendra toujours à établir un compromis... Et ce n'est certainement pas un point sur lequel ceux-ci insistent...

Arrivé ici, je suis certain qu'il y a toujours des dizaines de milliers de développeurs PHP qui comptent bien ne jamais utiliser de Framework, parce qu'ils sont les instruments du démon, et sont conçus par des fanatiques fou furieux (comme moi). PHP a la particularité d'être particulièrement lent et résistant à l'adoption d'un état d'esprit embrassant les principes de Frameworks d'applications Web, qui sont considérés comme acquis par d'autres langages. Notons que c'est en bonne partie dû au fait que PHP a sa large part de développeurs amateurs et d'experts auto-formés, en raison de la facilité avec laquelle n'importe qui peut commencer à apprendre et à utiliser PHP, sans oublier de mentionner le fait que PHP fait parti des plus anciens langages de programmation pour le Web encore utilisés aujourd'hui. D'une certaine manière, c'est aussi pour cette raison que PHP est souvent montré du doigt comme langage de programmation non sécurisé, de façon tout à fait injustifiée, puisque la plupart des problèmes de sécurité de viennent pas du langage, mais des développeurs peu informés qui ne lisent pas de livres ou d'articles mettant l'accent sur la notion sécurité. Je ne peux d'ailleurs qu'encourager vivement ceux qui se sentent concernés à ré-examiner leurs convictions, et à conserver un esprit ouvert : je ne suis pas méchant, pour autant que je sâche !

Pour utiliser Zend Framework, il faut que vous compreniez comment il est structuré et architecturé. De nombreux Frameworks suivent une approche "tout ou rien", ce qui suppose que vous suiviez les conventions et outils qu'ils fournissent, en ne vous écartant qu'au minimum de la piste tracée pour vous. De tels Frameworks ont été appelés "full stack" par Chris Hartjes, en référence au fait qu'ils s'attendent à ce que les développeurs utilisent toutes les fonctionnalités qu'ils offrent, sans pour autant exploiter d'autre bibliothèque externe. CakePHP, Django en Python, ou encore Ruby on Rails sont des exemples de Frameworks full stack. A l'opposé, Chris appelle Frameworks "glue" ceux qui permettent aux développeurs de choisir ce dont ils ont besoin, d'étendre n'importe quelle classe, ou même de remplacer des composants dans leur intégralité, et, en conséquence, leur accordent plus de liberté dans la structuration de leur application. Code Igniter et ezComponents sont des exemples de Frameworks glue.

Zend Framework est aussi un Framework glue. Toutes ses fonctionnalités sont conçues comme des composants faiblement couplés, qui sont capables d'exister en dehors du Framework. En somme, il s'agit d'un regroupement de bibliothèques, avec quelques éléments les rattachant ensemble, comme les composants MVC, qui définissent des conventions par défaut, donnant l'impression d'un Framework full stack lorsque vous les utilisez. Cette approche à base de composants est l'un des facteurs qui explique un bonne partie de la popularité de Zend Framework : il est possible de l'étendre et de le personnaliser plus qu'on n'aurait au premier abord tendance à l'imaginer. Chaque composants et classes peuvent être hérités, intégrés aux différentes couches du Framework, et utilisés avec des efforts minimaux. Certes, cela rajoute un peu de travail (si vous choisissez de suivre cette approche), mais cela signifie aussi que la seule limite à ce que le Framework permet de faire est votre imagination.

Il existe des composants qui vont bien au-delà des fonctionnalités attendues d'un Framework full stack, puisque la communauté a ajouté des fonctionnalités pour la génération de documents PDF, la mise en cache, l'aggregation RSS/Atom, l'intégration de Dojo ou jQuery, le support de plusieurs dizaines d'API Web Services, et bien d'autres encore, au-delà de cette liste quelque peu alétoire. L'autre aspect de sa popularité est que rien ne vous empêche d'utiliser tous ces composants en dehors de Zend Framework, par exemple pour des applications basées sur CakePHP, symfony, ou Code Igniter ! C'est une architecture vraiment ouverte et portable.

Donc, comment est-ce que Zend Framework s'en sort par rapport aux facteurs de choix que je mentionnais plus haut ? J'en ai relevé treize (ça porte malheur, diraient certains) au total.

Maintenabilité

Zend Framework est fortement maintenable, gràce à son support de sous-classes, son respect d'interfaces, son impressionnante suite de tests unitaires, et la supervision constante de la communauté. Il y a de nombreuses vérifications de compatibilité antérieure en place, en vue de s'assurer que chaque révision n'ait qu'un impact minime sur vos applications existantes ; on peut notamment citer l'accès SVN public, ou la forte résistance aux modifications de comportement.

Adaptabilité

Considérant sa nature de Framework "glue," ZF offre de fantastiques possibilités d'adaptation et de personnalisation. Je ne pense pas que nous soyons à court de classes ou de composants que vous puissiez adapter, surcharger, ou tout simplement, remplacer par d'autres alternatives existantes. Il existe déjà quantité de composants pré-adaptés, que vous pouvez télécharger indépendamment du Framework, et qui ajoutent des fonctionnalités que celui-ci ne fourni pas nativement.

Courbe d'apprentissage

La courbe d'apprentissage est partagée en deux étapes distinctes. La première est similaire à celle de n'importe quel autre Framework, et ne posera pas de réelle difficulté aux développeurs - ceci étant en bonne partie dû à à l'excellent Guide de Référence. La seconde étape est d'apprendre à utiliser l'adaptabilité du Framework à votre avantage, pour écrire des plugins, des extensions, et même de nouveaux composants, qui sont souvent nécessaires pour des applications réelles. C'est sans aucun doute une étape qui prend plus de temps, puisqu'elle s'acquiert avec l'expérience... Mais c'est exactement celle pour laquelle ce livre a été écrit.

Fonctionnalités et innovations

Des dizaines de composants, des centaines de classes, et une file de propositions quasi-interminable. Zend Framework n'est définitivement pas à court de fonctionnalités ! Pour ce qui est des innovations, le Framework a été pensé de manière à pouvoir embarquer des implémentations correspondant aux dernières technologies du Web. L'objectif est plutôt atteint, et vous verrez que Zend Framework fourni des implémentations de référence en PHP de technologies de partenaires tels que Google, Adobe, et Microsoft.

Qualité de la documentation

Il y a deux types de points de vue à propos de la documentation du Framework. Les deux s'accordent sur l'extrême importance du Guide de Reference, et sa bonne capacité de transmission d'information vers les développeurs. Mais il est quelque peu victime de sa très grande taille, qui rend certains détails difficiles à trouver, et à cause de laquelle certains points simples paraissent trop complexes, ou difficiles à déchiffrer. Ne considérez tout de même pas que la documentation est si mauvaise ! Elle est largement en avance sur celle de plusieurs autres gros Frameworks, qui arrivent à peine à vous proposer une documentation d'API automatiquement générée. Et le Guide de Référence n'est pas tout seul : vous avez aussi à votre disposition... oui... ce livre ! Pour être franc, je devrais ajouter qu'il y a trois autres livres actuellement publiés qui traitent du Zend Framework ; donc la partie documentation est plutôt bien couverte. Cela dit, notez que celui-ci est le seul qui soit libre ;-)

Support technique et communautaire

Un des arguments majeur de Zend Framework est qu'il est officiellement supporté par Zend Technologies Inc. Zend suppervise l'intégralité du processus de développement, en s'assurant que tous les composants soient approuvés, passés en revue, et que leur utilité soit réelle. Zend et ses partenaires mondiaux offrent également du support et des formations pour un prix qui intéressera pas mal d'entreprises. D'un point de vue communauté, vous disposez d'un grand nombre de listes de diffusion, channels IRC, et d'une commauté de bloggers, tous disposés à se rendre fou en tentant de répondre à chacune de vos questions. La plupart des ressources communautaires (en dehors des mailing lists) ont tendance à être indépendantes de Zend, et vous trouverez de nombreux sites et forums dans d'autres langues que l'anglais.

Régularité des mises à jour et corrections

Des mises à jour sont publiées fréquemment, avec un nouveau cycle de version mineure toutes les quelques semaines, intégrant corrections de bugs, nouvelles fonctionnalités, et améliorations de fonctionnalités existantes. Il n'y a pas de mises à jour uniquement orientées sécurité, ce qui peut être considéré comme problématique si de petits bugs s'accumulaient pour trop longtemps... Mais le calendrier de sortie des nouvelles versions est bien suivi, celles-ci sont fréquentes, et leurs dates relativement prévisibles.

Contrôle qualité

Le contrôle qualité est une des tâches de Zend, qui passe en revue tous les composants avant qu'ils ne soient acceptés pour des développements plus poussés et une intégration à la distribution officielle. Bien évidemment, il existe des composants qui ne sont pas parfaits en termes de fonctionnalités, facilité d'utilisation, ou d'autres facteurs du même type, mais ils sont peu nombreux, et, s'ils deviennent populaire, ils recevront généralement toute l'attention qu'ils méritent. Tous les composants du Framework sont rigoureusement testés unitairement, et la communauté, toujours en alerte, ne laisse pas passer grand chose ! Le Framework a récemment fait l'objet d'un événement "chasse aux bugs", et j'espère que ceux-ci se poursuivront dans le futur, de manière régulière.

Performances de base

La notion de performance de base est quelque chose qui doit être pris avec du recul. Considérant que chaque Framework a des pré-requis variés et des fonctionnalités différentes, il est difficile (et beaucoup diraient inutile) de les comparer sur un pied d'égalité. La principale chose que je dirais est qu'un usage judicieux de cache et d'optimisations éliminent la plupart des avantages qu'un Framework peut avoir par rapport à n'importe quelle autre, pour ce qui est des performances de base. Ne négligez pas cela, s'il vous plait ! Si l'interprétation de bencmarks est votre truc, cela dit, la meilleure source que je connaisse est une série de benchmarks effectuée par Paul M. Jones en septembre 2008 et mise à jour en mars 2009 pour corriger quelques points mineurs. Tous ses tests excluaient tout code d'application, en dehors du strict nécessaire requis pour un cycle complet de requête / réponse. Sur ce test et à l'époque, Zend Framework obtenait 78.93 requêtes par seconde sur le système Amazon EC2 de référence de Paul. C'est à comparer aux 61.84 requêtes par seconde de symfony, et aux 42.79 requêtes par seconde pour CakePHP, et 138.64 requêtes par seconde pour Solar. Code Igniter n'a pas été pris en compte pour les tests de Paul, mais il est probable qu'il battrait n'importe lequel des autres Frameworks cités, vu le segment de marché qu'il vise et son approche du développement. Globalement, on constate que Zend Framework est plus ou moins aligné avec ses concurrents principaux. Cela dit, je considère que le petit avantage qu'il a n'est absolument pas signicatif pour l'analyse globale.

Facilité de mise en place de tests

Je vais être honnête : c'est un peu le point qui me gêne le plus avec Zend Framework. Les lecteurs de mon blog savent que j'aime parler de Behaviour-Driven Design (BDD) et d'eXtreme Programming (XP). Ces pratiques demandent que la mise en place de tests automatisés soit bien supportée, afin que nous puissions pratiquer le BDD ou le Test-Driven Design (TDD) à fond. Zend Framework, principalement à cause de son esprit PHP, a réussi à magnifiquement se tirer une balle dans le pieds sur ce point : il ne dispose pas d'une API interne de tests ! Notez que je pourrais modèrer un peu mes propos en remarquant qu'il existe à présent un nouveau composant nommé Zend_Test, qui rend la mise en place de tests fonctionnels automatisés bien plus simple, si vous utilisez PHPUnit. Il agit comme un proxy abstrait autour du coeur du composant MVC, en offrant un bon niveau de contrôle sur l'initialisation de requêtes et les tests sur les réponses. Il ne satisfera pas tout le monde, mais il répond aux besoins de base, et sera suffisant pour la majorité des développeurs PHP. En fait, tant que les développeurs conservent un Modèle indépendant des couches Controlleur et Vue du Framework, les difficultés devraient être minimes.

Disponibilité d'hébergements

Zend Framework tourne sur une plate-forme PHP. Sérieusement : est-il nécessaire d'en dire plus ? Je pourrais aussi bien parler de la disponibilité de l'air, de la pollution, ou même des lapins : PHP a quelque chose en commun avec ces trois points : il est présent partout.

Support des bonnes pratiques actuelles

Zend Framework a toujours eu un tendon d'Achille : les tests. J'ai couvert ce point plus haut, et en dehors de cette critique, il n'y a rien qui empèche les développeurs d'utiliser leur propre type de fanatisme... Ou méthode de programmation (Ce qui peut être considéré comme du fanatisme pour quelqu'un de sarcastique qui apprécie l'autodérision... Comme moi).

Literature produite par la communauté

Dès le départ, Zend Framework a eu un bon contact avec la communauté. Sur n'importe quel sujet imaginable, vous trouverez quantité d'articles, livres (y compris celui-ci !), sections du guide de référence, et posts sur des blogs. Vous saviez que ce livre, lui-même, était au départ une série de 9 tutoriaux sur mon blog, n'est-ce pas ?

Treize facteurs plus tard, je pense que j'ai couvert à peu près toutes les bases. Le but du jeu était de vous familiariser un peu avec Zend Framework, et de vous insulfler un brin de ferveur fanatique (de façon à ce que vous poursuiviez votre lecture, et, peut-être, me donniez quelque argent pour mon nouveau Macbook Pro). Mais cela vous permet aussi d'aller jeter un coup d'oeil à d'autres Frameworks, en ayant une idée de quoi chercher, de manière un peu plus ordonnée. Après tout, même si votre attention devrait être attirée par Zend Framework tant que vous lisez ce livre, le monde est bien plus vaste que ce seul Framework !

1.2. A propos de ce livre

Zend Framework : Surviving the Deep End est écrit sous forme d'un tutorial détaillé, qui suit pas à pas le développement d'une application réelle. Les sujets sont organisés d'une manière cohérente, et vous trouverez fréquemment des références aux chapitres précédents, dans le but de renforcer ce que vous apprenez au fur et à mesure que vous lisez. Ce livre a été conçu de manière à regrouper des éléments du Guide de Référence, une partie du savoir grandissant de la communauté dans son ensemble, ainsi que des éléments issus de ma propre expérience, afin que les dévelopepeurs puissent se faire une meilleure idée du développement d'une application réelle avec Zend Framework.

A mes yeux, cela a toujours été le principal problème du Framework : le Guide de Référence ne fait pas grand chose de plus que présenter chaque composant de manière totalement indépendante. Il ne propose pas une approche orientée développement, ni un mode de pensée, ni même une liste de sujets avancés qui combineraient plusieurs composants. Notez tout de même que ce livre ne vient pas en remplacement du Guide de Référence : je considère que vous pouvez consulter celui-ci, indépendamment de ce que vous lirez ici. Après tout, le Guide de Référence est gratuit, détaillé, et il est raisonablement simple d'y trouver l'information que vous recherchez. Ce livre est donc à voir comme un complément au Guide de Référence, et non comme une solution de substitution.

Ce livre inclu l'intégralité du code source de l'application au sein du texte, et pourra même le répéter plusieurs fois pour mettre en évidence les modifications que j'apporterai. Je comprends parfaitement que des pages entières de code source peuvent être frustrantes à parcourir, mais cela améliore la compréhension - et c'est important à mes yeux. Pour des raisons de simplicité, le code source complet et finalisé de chaque chapitre est aussi disponible sous forme d'un téléchargement indépendant, comme détaillé plus bas.

Au fur et à mesure des chapitres, je ferai référence à plusieurs bibliothèques et composants externes, qu'il vous faudra installer. Je peux d'ores et déjà citer PEAR, le Framework CSS Blueprint, jQuery, HTMLPurifier, et PHPUnit. Je sais très bien que ce choix peut refroidir certains d'entre vous, mais je vous assure que leur installation sera couverte en détails, et qu'elle est plutôt simple, même pour des débutants. Vous devriez de toute façon garder à l'esprit que les projets réels ont généralement besoin de plusieurs bibliothèques externes !

Pour terminer, notez que ce livre suppose que vous avez des connaissances de base de PHP 5, SQL, et Programmation Orientée Objet (POO). Ce sont des compétences nécessaires si vous voulez apprendre à développer avec Zend Framework, mais elles ne seront pas présentées en détail dans ce livre. Cela dit, considérant que PHP est dans l'ensemble facile d'accès, je n'ai aucun doute quand au fait que vous parviendrez à trouver en ligne toutes les informations dont vous pourriez avoir besoin pour vous mettre sur les rails de PHP.

1.2.1. Obtenir le Code Source pour les Chapitres

Le code source de tous les chapitres est maitenu publiquement sur Github.com, en utilisant un repository git. Vous pouvez trouver le code source d'un chapitre donné en naviguant jusqu'au tag correspondant. Par exemple, le code source du chapitre 10 peut être trouvé à l'url http://github.com/padraic/ZFBlog/tree/Chapter-10. La décision d'utiliser git était facile, avec Github. Si vous n'êtes pas familier avec ce système de contrôle de versions, Github propose une fonctionnalité de téléchargement pour tous les tags et branches. Voici tout de même un rapide apperçu de comment obtenir le code source d'un chapitre en utilisant git.

Pour récupérer le code source depuis le repository, vous allez devoir cloner celui-ci. Le Clonage est l'équivalent de la méthode checkout de Subversion. Pour cloner le repository vers le répertoire ./zfblog, utilisez la commande suivante depuis une console :

git clone git://github.com/padraic/ZFBlog.git zfblog

Vous devriez voir le clonage s'effectuer relativement vite (git est rapide !) :

Initialized empty Git repository in /home/padraic/projects/misc/zfblog/.git/
remote: Counting objects: 120, done.
remote: Compressing objects: 100% (94/94), done.
remote: Total 120 (delta 31), reused 0 (delta 0)
Receiving objects: 100% (120/120), 19.63 KiB, done.
Resolving deltas: 100% (31/31), done.

Par défaut, ceci vous placera dans la branche "master". Contrairement à Subversion, git n'utilise pas une arborescence typique de trunk/branches/tags, mais la branche "master" est ce qui se rapproche le plus de trunk pour de nombreux projets. Tout le contenu du répertoire ./zfblog sera issu de cette branche. Puisque vous serez probablement intéressé par l'utilisation du code source sur la base de chaque chapitre, plutot que par la version complétée du Chapitre X, vous aurez besoin d'obtenir la version taggée la plus appropriée. Listez tous les tags disponibles en utilisant :

git tag -l

A vrai dire, accéder à un tag ou à une branche avec git peut sembler étrange lorsque l'on a l'habitude de Subversion. Tout d'abord, ceux-ci n'ont pas de chemin physique ! A la place, vous "extrayez" une branche ou un tag, et git met à jour le répertoire courant avec son contenu. Vous pouvez extraire n'importe quelle branche ou tag, y compris master, à n'importe quel instant. La fusion de branches fonctionne de la même manière : vous n'avez pas besoin que les chemins de chacunes d'entre-elles soient physiquement présents. Ceci peut sembler très étrange au premier abord, mais vous vous y ferez vite. Vous réaliserez aussi que brancher est extrêmement peu coûteux et simple avec git. Pour extraire le tag Chapter-10, vous devrez lancer la commande reproduite ci-dessous :

git checkout -b Chapter-10

Votre répertoire de travail est maintenant mis à jour à l'état de ce tag, et vous obtiendrez le message de résultat qui suit :

Switched to a new branch "Chapter-10"

Vous pouvez maintenant visionner le code source du chapitre qui vous intéresse sans que les futures modifications (appliquées à master) ne viennent interférer. Vous pouvez basculer vers une autre branche ou un autre tag de la même manière. L'option -b n'est en fait requise que lorsque vous extrayez une branche ou étiquette pour la première fois : cela crée une branche locale, qui pourra être mise à jour depuis le repository.

Si jamais vous vous perdez (ce qui est facile, sans les chemins physiques !), vous pourrez retrouver sur quelle étiquette ou branche vous vous trouvez actuellement en utilisant la commande suivante :

git branch

Sans paramètre, elle vous renverra la liste de toutes les branches et étiquettes existantes, et positionnera une étoile devant la branche courante :

* Chapter-10
  master

Pour conclure, notez que les prochains chapitres pourront inclure des fichiers de configuration fournis sous forme de fichiers .example ; cela indique qu'ils devront être copiés et modifiés avant de pouvoir être utilisés. Cela arrivera notamment lorsque les options contiendront des données privées, telles des clefs d'API, ou d'autres informations du même type.

1.3. Moi, Moi, Moi !

Ce livre n'est pas à propos de moi, mais en tant qu'auteur, je suis à peu près inévitable !

Je suis un développeur PHP avec maintenant quelque chose comme dix ans d'expérience, y compris dans d'autres langages comme Java, Ruby, et C/C++. Durant pas mal de ces années, j'ai édité un blog à l'URL http://blog.astrumfutura.com ; j'ai passé des heures chaque mois à écrire des articles ou tutoriaux à propos de mes pensées, opinions, et centres d'intérêts. Je vis en Irlande, et j'espère que ce sera toujours le cas : j'aime énormément cette petite ile.

Je suis connu comme quelqu'un d'opiniâtre avec un certain sens de l'humour. Je ferai des plaisanteries tout au long de ce livre, et, quelque soit leur qualité, vous êtes supposé sourire, ou même rigoler quelques secondes après les avoir lues. Allez ! Je sais que vous en avez envie... J'ai parfois été très critique par rapport à certaines fonctionnalités de Zend Framework, ou certains aspects de sa philosophie, et je vais continuer à l'être ; vous pouvez vous attendre à ce que j'exprime ces opinions (dans une certaine limite) au cours de ce livre, puisque je pense qu'elles illustrent certains points auxquels les développeurs devraient prêter attention, et leur donnent des avertissement clairs et justifiés quand les choses ne sont pas parfaites. Après tout, le titre de ce livre n'est pas "Aveuglément chanter les louanges de Zend Framework". Chaque Framework a ses points faibles, quoi qu'en disent leurs développeurs. Connaître ces points faibles, et savoir comment les contourner, est une très bonne chose.

Enfin, je suis un contributeur du Zend Framework. J'ai proposé et travaillé sur Zend_View, Zend_Oauth, Zend_Crypt, Zend_Feed_Reader, Zend_Feed_Pubsubhubbub, Zend_Service_Yadis, et Zend_Captcha_Recaptcha. J'ai d'ailleurs d'autres propositions en cours et non encore terminées. En théorie, cela signifie que j'ai tendance à savoir ce que je fais, juste au cas où vous pensiez que je sois dingue ou dans le genre. Cela dit, s'il m'arrive de dire quelque chose d'erroné, dites-le moi, et je corrigerai le problème !

1.4. A propos de cette traduction

Ce que vous lisez actuellement est la traduction française du livre "Zend Framework: Surviving The Deep End", qui a initialement été rédigé en anglais, par Pádraic Brady.

Cette traduction a été réalisée par moi-même, Pascal MARTIN - et cette section de ce chapitre est une des seules parties de ce livre où je m'exprimerai à la première personne : tout au long du livre, j'ai utilisé "je" là où c'est Pádraic qui s'exprime.

Je suis développeur PHP depuis quelque chose comme 7 ou 8 ans en amateur, et plus de 3 ans professionnellement parlant. J'habite en France, à Lyon.

Je publie occasionnellement des articles parlant principalement de PHP et de Javascript sur mon blog perso : http://blog.pascal-martin.fr/ ; et vous pouvez me suivre et/ou me contacter sur twitter : http://www.twitter.com/pascal_martin

Vous avez des commentaires, remarques, suggestions, idées d'améliorations, remerciements, ... à propos de la traduction française de ce livre ? N'hésitez pas à me contacter par e-mail : contact _at_ pascal-martin.fr ; je met souvent pas mal de temps à répondre, cela dit...

Et je profite de cette occasion pour vous souhaiter une très bonne lecture, et un excellent apprentissage du Zend Framework !

1.5. Vous, Vous, Vous !

La nature de ce livre pourra parfois vous sembler quelque peu étrange : il est organisé autour d'une application, et ne constitue pas une mise à plat des composants de Zend Framework ; les connaissances vous seront proposées au fur et à mesure que notre application en aura besoin. Cette approche est fortement pratique, et conçue de manière à mettre en avant l'application dans sa globalité, et non pour insister sur chaque petit détail de tous les composants... qui sont largement couverts dans le Guide de Référence.

Pendant que vous lirez le livre, je vous encourage vivement à expérimenter par vous-même. Il n'y a pas une seule et unique façon de développer une fonctionnalité dans une application, alors n'hésitez pas à vous écarter des pistes que je vous proposerai, et à essayer les choses à votre manière : vous apprendrez plus ainsi !

Si vous avez envie de participer, vous pouvez explorer n'importe quelle section du livre, et même vous exprimer sur le site officiel http://www.survivethedeepend.com sur lequel sont hébergés une section de commentaire pour la version en-ligne du livre, et un forum pour poser des questions aux autres lecteurs (et à moi aussi, je suppose !). Vous pouvez aussi me laisser une courte note sur Twitter, à http://www.twitter.com/padraicb.

Et maintenant, asseyez-vous, détendez vous, conservez vos appendices à l'intérieur du cockpit, et tournez la page pour accéder au Chapitre 2.