ZF2 – utilisation des vues

les vues dans ZF2 – Zend\View

(article en cours de rédaction)

Dans un context MVC (Model, Vue, Controlleur), les controllers vont renvoyer des données brutes (qu’ils ont, éventuellement, récupéré du model (DB, fichiers de donnée)), les vues serviront à transformer/décorer ce résultat pour l’afficher coté utilisateur.

Les vues sont donc une composante essentielle de la couche présentation. Elles ont la responsabilité de présenter le résultat, en lui faisant subir les transformations nécéssaires (mises en forme du résultat ou des éventuelles collections de données qu’il contient. Mise en forme des formulaires à afficher dans une vue, etc…).

le rendu du résultat des vues peut se faire dans un format donné : html, json, xml (rss) , autre … )

la représentation initiale du résultat (retourné par le controller), ne contient pas de mise en forme, et se transmet à la vue, par défaut, via un objet ViewModel() contenant les données retournées par l’action du controller.

Pour retourner un résultat à partir d’un controller, on peut, soit renvoyer un Objet ViewModel() en lui passant en paramètre un tableau contentant le résultat, soit renvoyer directement le tableau de résultat.
Dans ce deuxième cas un ViewModel sera automatiquement créé (par le CreateViewModelListener qui est déclenché en cours de ‘dispatch’):

renvoi de résultat, à partir de l’action:

il est possible de passer des paramètres à un objets ViewModel() de plusieurs manières:

l’accès à ces données brutes pour les transformer se fait dans la vue. on parlera de template de vue:
par défaut on utilise des fichiers *.phtml comme templates, ( il est possible d’utiliser d’autre type de template (smarty, twig, etc…)
les fichiers .phtml sont des fichiers html dans lequel on ajoute du code php en vue de tranformer le résultat pour l’afficher. on évitera d’y mettre du code php spaghetti pour faire des choses complexe.

récupération du résultat dans le template:

plusieurs manières d’accéder aux variables dans la vue existent.

Les lignes suivantes renvoient le même résultat:

la première méthode est la plus conseillée: on utilise une variable de l’instance de PhpRenderer.
la deuxième utilise un appel explicite au conteneur de variable du PhpRenderer.
la troisième méthode est le résultat d’une extraction à partir du conteneur de variables de PhpRenderer

l’objet ViewModel rempli d’autres tâches supplémentaires (il contiendra, par exemple,  le nom du template à utiliser.
le template à utiliser est injécté en cour de ‘dispatch’ par InjectViewModelListener (qui va determiner le template en fonction de l’action/controller).
si nécéssaire, on peut spécifier un template spécifique à utiliser dans l’action (se qui va bypasser l’injection du nom du template).

par défaut dans ZF2, un template est utilisé pour une action. les templates d’un module sont placé par défaut dans le dossier view du même module. Des sous-dossiers sont nommés en minuscule: le premier porte le nom du module. dans ce dossier on trouvera un dossier par controller, dans lequel on trouvera un fichier .phtml par action

voici le cas de l’IndexController du module Application (qui contient dans l’exemple les actions indexAction et autreAction )

par défaut, dans ZF2, le redu des vues se fait en deux étapes : la vue correspondant au résultat d’une action d’un controller, est à son tour injectée dans une vue globale qui sert de gabari : un(e) layout
le but d’un layout est de factoriser le rendu du code html se trouvant sur toutes les pages (head, header, footer, etc…), pour éviter d’avoir à le coder dans chaque vue
N.B. des vues spéciales seront utilisées pour des besoins spécifiques (page d’erreur par défaut, erreurs 404 etc…).

concernant l’organisation des vues/controllers une arborescence  recommandée par l’équipe ZF2 est utilisé par défaut, dans le skeleton, et on pourra la personnaliser au besoin.

Ci-dessous l’arborescence du module Application (avec la traduction en moins):

configuration de base des vues dans le ViewManager

pour le chargement des vues, le gestionnaire de vues a besoin qu’on lui spécifie où les trouver. pour cela on renseigne les paramètres template_path_stack et template_map

le template_path_stack sert à renseigner des chemins où chercher les templates, tandis que template_map sert à renseigner explicitement chaque template en fournissant la paire ‘nomdutemplate’ => ‘chemin/du/template.phtml’. la configuration ressemblera à ceci :

le nom du template à utiliser est, par défaut, déterminé en fonction du module/controller/action (par le view resolver). ce template est ensuite récupéré, dans le cas de notre configuration, en cherchant le fichier phtml correspondant dans template_map et si il n’y est pas trouvé, il est recherché dans les dossiers spécifiés dans template_path_stack ( view_dir/module/controller/action.phtml )

même si une simple ligne de paramétrage du template_path_stack dans chaque module fait l’affaire pour trouver les templates à utiliser, il est recommandé de spécifier les templates utilisés dans template_map pour des raisons de performances (imaginez que vous avez 20 modules dans votre appli, vous aurez une problématique qui ressemble à celle des include path surchargés, un template sera récupéré après un scanne des dossiers view des différents modules, y a un peu de gaspillage de perf )

à titre de comparaison, le template_path_stack est au template_map ce que le StandardAutoloader est au ClassMapAutoloader

choix d’un template spécifique

on utilise la méthode setTemplate() du ViewModel():

assurez vous que le template existe (avec les bon droits) et que le viewManager sait le trouver (config)

layout par défaut

par défaut, si l’on ne spécifie pas de layout, ‘layout/layout’ est utilisé.
on peut spécifier un layout par défaut comme ceci :

choix d’un layout spécifique

il peut arriver que l’on aie besoin d’utiliser un layout spécifique à certaines vues.

pour cela, on crée un layout en s’assurant d’y spécifier l’endroit où la vue courante sera affichée. par défaut, la vue courant est récupérée dans la variable $this->content du layout.

on se contente de l’afficher là où l’on a besoin d’afficher la vue, voici un exemple simple :

il arrive que l’on répète certaines tâches dans les vues (par exemple traduire une chaine de caractères, mettre en forme un commentaire, afficher un avatar, etcc…). on utilisera des aides de vue ( ViewHelper ) qui sont des fonctions accesibles dans nos vues en vue de faire des tâches répétitive ou complexes. on appelera une aide de vue comme ceci : $this->translate(‘text à traduire’);

dans le cas d’un layout, une tâche réccurente pourrai être d’afficher des metas, ou de lier des fichiers javascripts et css.

dans l’exemple suivant on utilise des aides de vue dont le but est d’inclure d’une manière plus élégantes les données d’entête de page (headTitle(), headMeta(), headLink(), headScript() )

il arrive que certaines vues utilisent des librairies javascript ou des style css non utilisés par d’autres. ces aides de vues servent à éviter de surcharger les layout de code non utilisée dans toutes les pages, en les utilisants dans les vues pour ce qui est spécifique à ces vues, et dans le layout pour ce qui est général.

par défaut on le place dans le dossier view/layout du module.
on informe le ViewManager de son existence (dans l’exemple on l’appelle simple.phtml) :

enfin dans les actions concernées on spécifie le layout à utiliser comme ceci :
(on utilise la méthode setTemplate() de la vue du laout)

le template de vue pourrai ressembler à ceci (hello.phtml):

 

rendu d’une vue sans layout

rendu d’une vue en json

activons la stratégie json dans la config du ViewManager:

rendu simple (notre action renvera toujours du json)

rendu conditionnel :
par exemple si on reçoit une requête ajax, on revoie du json, sinon du html:

envoie d’un résultat à un endroit du layout

on peut envoyer une variable dans notre layout comme ceci :

on peut aussi renvoyer une vue à un endroit du layout.(pas de template de vue spécifié, le résultat est manipulé dans le layout comme dans une vue normale)

dans le layout :

on peut décider d’envoyer un résultat à partir d’une vue vers notre layout
voici, par exemple, un résultat dans notre action

dans la vue on utilise l’aide de vue placeholder() pour faire persister un resultat entre plusieurs vues:

dans le layout, on récupère le résultat, avec le même viewHelper (placeholder()):

utilisation de vues imbriquées

(suite en cours de rédaction)

Did you like this? Share it:

One Response to ZF2 – utilisation des vues

Open Close