Les articles de GNU/Linux Magazine Hors-Série N°58

Le framework Zend est un outil de développement permettant de réaliser des applications de manière professionnelle en proposant à la fois des méthodes de développement, mais aussi un moyen de les mettre en pratique qui est le framework lui-même.C’est ainsi qu’il faut voir les choses. Cependant, il est nécessaire de comprendre que le framework est un élément parmi d’autres et qu’il utilise un langage de programmation, en l’occurrence PHP.Il est donc nécessaire d’utiliser les bonnes pratiques de PHP et les outils permettant d’optimiser son fonctionnement, d’autant que ces derniers deviennent indispensables et que le framework est réellement prévu pour fonctionner avec eux.

L’objectif de ce court article est de présenter la manière préférentielle d’installer une version précise du framework Zend 2 et la manière d’installer la version en cours de développement.

Cet article va introduire les règles qu’il est nécessaire de connaître pour commencer à créer une nouvelle application en utilisant le framework Zend 2.Il va présenter les différences notables avec la première branche, mais il est accessible à ceux qui ne la connaissent pas.Il est à noter, avant même de commencer, que ZF2 n’est pas encore terminé et que certaines fonctionnalités essentielles sont manquantes. Ceci explique la complexité relative de ce qui est abordé dans ce chapitre et qu’il est nécessaire de comprendre avant même de commencer à rédiger le contenu de son premier module, alors que certaines de ces notions pourront être abordées après la rédaction du module, avec la version définitive.Toujours est-il que ce qui est dit ici restera valable, mais pourra être abordé plus tard dans le processus de développement. Ce premier article regroupe les changements les plus importants entre ZF1 et ZF2.

La couche de persistance d’une application est l’élément le plus essentiel. Les frameworks tels que ZF2 sont conçus pour créer des applications au-dessus de bases de données relationnelles. Ils disposent donc de tout l’arsenal nécessaire pour gérer les différentes bases de données du marché et leurs spécificités, mais également pour proposer des méthodes efficaces pour gérer les données lues ou écrites en base, via un ORM performant.

Dans le modèle MVC, la vue représente toute la couche de présentation. Il s’agit de présenter les données en les organisant dans une page HTML ou dans un document, mais également de les présenter sous une forme lisible (en transformant une date brute en chaîne de caractères représentant une date lisible, …). Pour ce faire, ZF2 utilise les fichiers PHTML pour assurer l’écriture de fichiers HTML et utilise des aides de vues pour la conversion de données.

Le contrôleur est le dernier des éléments du patron d’architecture MVC. C’est un chef d’orchestre qui fait travailler des modèles, utilise tout l’environnement qui a été construit pour lui et mis à sa disposition et pousse des données dans la ou les vues.

Le formulaire version ZF1 est un composant au croisement du modèle (il utilise des données issues d’un modèle et il propose une saisie conforme au modèle) de la vue (ce composant peut être rendu sous forme HTML) et du contrôleur (processus de validation et de filtrage des données). La volonté de ZF2 est de clarifier cette séparation.C’est un composant clé qui est essentiel pour se faciliter à la fois l’impératif travail de validation des données, mais également celui de présentation par la description de chaque champ. Il permet de reproduire des pratiques standardisées en étant assuré du type de données que l’on va recevoir lorsque le formulaire sera validé.Il est également nécessaire de parler de la problématique de décoration, au cœur des difficultés de programmation les plus importantes avec ZF1 pour tous ceux qui ont eu la volonté de ne pas utiliser les voies standardisées.

L’article sur les règles basiques d’architecture a présenté le composant MVC qui serait, s'il ne fallait en choisir qu’une, la principale nouveauté de ZF2. Il a également présenté la requête, la réponse et le routeur, ainsi que les généralités sur les modules. L’objectif était de fournir toutes les informations nécessaires pour aborder l’écriture de modules et les 4 autres articles qui suivent ont décrit ce qu’il fallait pour les construire.L’article présent est un complément à ce premier article qui traite plus particulièrement de certaines notions dont on peut se passer pour comprendre l’écriture d’un module mais restent très utiles au niveau de l’application. Les 4 articles qui suivent traitent chacun également d’un de ces domaines.

Les Controller plugins ou aides d’action sont un élément important de ZF1. Ils offraient un moyen de réaliser des actions complexes courantes de manière réutilisable. Il ne faut pas les confondre avec les plugins d’application qui se situaient à un niveau plus haut et permettaient de réaliser des actions transverses assez facilement, comme la gestion d’une pile de dispatch, par exemple. Pour qu’ils fonctionnent, il fallait qu’ils s’enregistrent et qu’ils implémentent des hooks qui leur permettaient de se déclencher au moment venu. Or, ZF2 a totalement modifié sa façon de procéder. Maintenant, on utilise les événements. Ceci a totalement bouleversé les plugins au sens ZF1, mais a facilité l’écriture d’aides d’action et leur utilisation. Le nom « Plugin » leur est dédié.

La mise en page est traitée dans un article dédié pour la différencier de la notion de vue et parce que pour ZF1, cette mise en page était traitée à part. Pour ZF2, la mise en page est un élément de configuration comme un autre et est réalisée très simplement.

Comme on l’a vu tout au long des articles précédents, l’architecture du framework et donc les architectures des applications ont largement évolué. Un élément clé de cette architecture sont les règles qui régissent le chargement des classes.

ZF1 proposait une exception par composant ou sous-composant. ZF2 revoit toute la façon de faire et l’adapte à l’utilisation des espaces de nommage.Savoir comment fonctionne le système d’exception permet de comprendre leur utilisation dans les composants, mais surtout, permet de les utiliser de manière conforme lorsque l’on créera nos propres exceptions.

Dans les articles précédents, ont été présentés quelques composants parmi les plus essentiels et la manière dont il faut les utiliser, voire celle dont ils fonctionnent. Cette quatrième partie du hors-série sur ZF2 permet d’aller plus loin dans les concepts utilisés par le framework et de présenter en détails les connaissances qu’il faut avoir au préalable pour lire son code.

Cet article va présenter ce qu’est l’injection de dépendance et de quelle manière elle est utilisée au sein de ZF2.

Une annotation est à la base un élément de programmation assez peu standardisé permettant de gérer des métadonnées d’un code source. On trouve différentes notions regroupées sous le terme d’annotation, parmi lesquelles la fourniture de documentation au format PHPDoc. En ce qui concerne ZF2, la notion d’annotation est définie par l’interface Zend\Code\Annotation\Annotation.

Comme on a pu le voir dans les articles précédents, les événements sont au cœur de ZF2. Lorsqu’on ne se concentre que sur le modèle, la vue et le contrôleur, ils sont utilisés sans que l’on en ait forcément conscience, car au cœur du processus Mvc. La première partie de cet article va les détailler. Le gestionnaire d’événements est également prévu pour être utilisé à n’importe quel moment pour résoudre des problématiques qui auparavant nécessitaient d’écrire des classes spécifiques avec des hooks spécifiques. La seconde partie va présenter la manière de jouer avec ce gestionnaire.