Atelierzf Zend Layout

5/11/2018 Atelierzf Zend Layout - slidepdf.com

http://slidepdf.com/reader/full/atelierzf-zend-layout 1/11

Atelier Zend Framework: Introduction

au templating avec Zend_Layout

par Julien Pauli (Tutoriels, article et conférences PHP et developpement web) (Blog)

Date de publication : 21/01/2008

Dernière mise à jour : 07/12/2010

L'intégration et l'utilisation de template sont indispensables sur le web. #Zend_Layout est

le composant natif de Zend Framework qui représente une solution flexible d'intégration

de vues.

Voyons ensemble à quoi ressemble #Zend_Layout et introduisons aussi quelques autres

composants qui s'interconnectent bien ensemble.

Nous allons décrire quelques utilisations possibles, allant du fonctionnement des layouts,

jusqu'à l'application d'une approche MVC dite 'push'.

http://blog.developpez.com/index.php?blog=126

http://julien-pauli.developpez.com/

http://developpez.net/forums/member.php?u=99082

http://www.developpez.com/



Atelier Zend Framework: Introduction au templating avec Zend_Layout par

Julien Pauli (Tutoriels, article et conférences PHP et developpement web) (Blog)

- 2 -Copyright © 2007 - Julien Pauli. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes,documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 Ede dommages et intérêts.

http://julien-pauli.developpez.com/tutoriels/zend-framework/atelier/zend-layout/

I - Zend_Layout: définition et buts.............................................................................................................................. 3

I-A - Principe...........................................................................................................................................................3

I-B - Configuration.................................................................................................................................................. 3

II - Intégration dans le modèle MVC........................................................................................................................... 5

II-A - Le fichier de template................................................................................................................................... 6

II-B - Modèle MVC push........................................................................................................................................ 7

II-B-1 - Couple plugin/aide d'action: ActionStack............................................................................................. 9II-B-2 - Aide de vue 'action'............................................................................................................................10

III - Conclusion...........................................................................................................................................................11














I - Zend_Layout: définition et buts

#Zend_Layout est un composant basé sur le design pattern "Two Step View" (vue en 2 temps). Son but est clair:

offrir un moyen d'utiliser le templating, à savoir d'intégrer des vues, dans des vues.

Comme à son habitude, Zend Framework offre une flexibilité très bonne. Le composant #Zend_Layout est livré avec

une configuration de base, mais il est appréciable de noter qu'elle est complètement personnalisable.Les services de #Zend_Layout son multiples (et surtout utilisé dans un cadre MVC) :

1 Rendre automatiquement un ou des templates (un template est une vue contenant d'autres morceaux de

vues) ;

2 Fournir un moyen de configurer l'objet Layout (nom des templates, chemins...), par défaut il suit les mêmes

règles que l'objet ViewRenderer ;

3 Permettre une approche utilisant le modèle MVC de ZF, ou pas (indépendance).

#Zend_Layout apporte une solution native élégante au problème du templating. Accompagné d'une petite panoplie

d'aides de vue, il va nous rendre bien des services pour un design efficace.

I-A - Principe

Le principe du two step view est résumé ici. Nous savons que par défaut, grâce à ViewRenderer , chaque action

rend une vue.

Ce principe reste totalement inchangé. Ce qui change en activant les layouts, c'est qu'au lieu que la vue soit rendue

telle quelle; son rendu va être intégré dans une vue de plus haut niveau, appelée Layout, ou template (on peut jouer

sur les mots). C'est le principe de la vue en 2 temps :

1 On rend la vue désirée, en général grâce à ViewRenderer (automatique : correspond à l'action dispatchée) ;

2 On rend un layout, dans lequel va être intégrée la vue précédemment rendue, ainsi qu'éventuellement,

d'autres vues, issues éventuellement aussi, d'autres actions parallèles.

Le layout est donc un fichier .phtml (une vue, oui), dans lequel on va marquer à quels endroits on veut rendre quelle

vue, ou quelle action.

Quelques notions peuvent paraitre complexes, mais il n'en est rien.

I-B - Configuration

Bien qu'il soit possible de mettre des layouts dans les layouts (etc...), cet atelier restera simple et utilisera un seul

template; c'est d'ailleurs un cas assez fréquent sur le terrain.

La configuration est simple: nous avons un objet Zend_Layout (on ne sait pas comment, pour le moment admettons

le) , il faut qu'il connaisse plusieurs choses :

1 Le fichier de template, c'est une vue classique de design global, mais elle va contenir des 'marques' pour

savoir où rendre les vues unitaires (clé de configuration layout , valeur par défaut: layout.phtml ;2 Le chemin d'accès aux fichiers de templates, nous avons dit que dans cet atelier nous n'aurons qu'un seul

template (clé de configuration layoutPath, valeur par défaut: chemin du script de vue courant ) ;3 L'attribut de l'objet layout qui contiendra la vue actuellement rendue par le processus MVC (vue principale)

(clé de configuration contentKey , valeur par défaut: content )

Accessoirement, il est possible de configurer d'autres paramètres relatifs à la personnalisation du rendu du layout.

Zend_Layout est configurable de différente manière, compatible avec Zend_Config et Zend_Application (plugin

de ressource).

#Zend_Layout fonctionne soit de manière couplée au système MVC de ZF (Zend_Controller_*), soit de manière entièrement autonomme.


http://julien-pauli.developpez.com/tutoriels/zend-framework/atelier/viewrenderer/



http://martinfowler.com/eaaCatalog/twoStepView.html













Pour se lier au modèle MVC, #Zend_Layout utilise uncouple plugin MVC/aide d'action qui est personnalisable (trèsbonne fléxibilité). Par défaut Zend_Layout_Controller_Plugin_Layout et Zend_Layout_Controller_Action_Helper_Layout sont utilisésNous utiliserons #Zend_Layout dans un contexte MVC dans la suite de cette article.














II - Intégration dans le modèle MVC

Pour entrer directement dans le vif du sujet, voici un exemple de template (de Layout), issu de la documentation

officielle, ce fichier est donc un fichier .phtml (par défaut) :

A première vue on semble comprendre comment cela fonctionne, mais il y a des astuces au niveau conceptuel à

bien intégrer:

Déja, il faut pouvoir initialiser le Layout. En effet, notre modèle MVC n'est pas affecté par Zend_Layout, avant qu'on

ne le lui spécifie clairement.

Ainsi, si vous ne touchez à rien, votre application MVC ne va pas utiliser Zend_Layout par défaut. Pour l'utiliser,Zend_Layout fournit une méthode statique : startMVC().

activation des layouts dans le modèle MVC

<?php

$config = new Zend_Config_Ini('config.ini');

Zend_Layout::startMvc($config->layout); // activation des layouts, sans ça, le modèle MVC demeure le même que celui que vous connaissez

// activation de MVC et lancement (dispatch())

config.ini

layout.layout = templatelayout.contentKey = contenu













Comme dans tous mes ateliers, j'essaye d'aller droit au but. Ce bootstrap simplifié montre comment lier Zend_Layout

au système MVC.

Si vous utilisez Zend_Application, un plugin de ressource, Zend_Application_Resource_Layout est utilisable et

invoque startMVC() pour vous:

Activation des layouts au moyen de Zend_Application

resources.layout.layout = template

resources.layout.contentKey = contenu

J'ai décidé que mon fichier de template s'appelle template, il se situe à la racine de mon dossier de vue (comportement

par défaut: je n'ai pas spécifié de paramètre layoutPath), et dans ce fichier l'attribut qui me permettra de rendre le

contenu de la vue actuellement dispatchée s'appelle contenu . Par défaut, je ne l'ai pas changée non plus, l'extension

d'un fichier de template est la même que celle des vues, à savoir phtml .

La méthode startMVC() effectue plusieurs actions : Elle crée une instance de Zend_Layout, puis elle enregistre le

plugin et l'aide d'action précisés (si non précisés, les classes par défaut citées plus haut seront utilisées).

Le plugin est enregistré avec un numéro de pile de manière à ce qu'il soit l'avant dernier à intervenir, sur l'évènementMVC postdispatch, le dernier plugin étant errorHandler .

Son rôle est de prendre la vue rendue automatiquement par viewRenderer , puis de rendre le fichier de template en

intégrant le contenu de cette vue dans l'attribut spécial de rendu (dans notre cas: template).

Les rôles du plugin et de l'aide d'action sont essentiels:

L'aide d'action permet de partager l'objet Zend_Layout à tout contrôleur, ainsi, dans toute action, $this->_helper->layout est l'instance de Zend_Layout utilisée dans MVC (et configurée en bootstrap).

Le plugin va enregistrer un évènement en postdispatch permettant de detecter quand rendre automatiquement le

script de layout (pas de redirection, pas d'exceptions ...).

Enfin une aide de vue, Zend_View_Helper_Layout, va permettre d'accéder à l'objet Zend_Layout dans la vue.

Dans toute vue, $this->layout() retourne l'objet Zend_Layout utilisé dans MVC (et configuré en bootstrap). Similaire

à l'aide d'action, oui.

Nous allons rapidement passer à la pratique, simplement notez que le plugin et l'aide d'action sont changeables au

moyen des méthodes setPluginClass() et setHelperClass(). Vous pouvez aussi passer votre propre objet de vue

à Zend_Layout, via setView().Par défaut Zend_Layoutextrait la vue de viewRenderer, vous n'avez donc qu'un objet vue dans tout votre processus,

sauf si vous désirez un comportement alternatif.

MVC ou pas, Zend_Layout a besoin d'un objet Zend_View_Interface pour fonctionner,notamment pour rendre le fichier de tem plate.

II-A - Le fichier de template

Voici ce à quoi ressemble notre fichier de template (incomplet point de vue HTML).

Notez qu'il n'a rien a voir avec le schéma ci dessus, qui est un schéma d'exemple issu de la documentation officielle.

script de layout

<div class="header">

<?php echo $this->layout()->header ?></div><div class="main">

<div class="gauche">

<?php echo $this->layout()->gauche?> </div>

<div class="content"> <?php echo $this->layout()->contenu?> </div>





http://julien-pauli.developpez.com/tutoriels/zend-framework/atelier/mvc-exceptions2/












script de layout <div class="droite">

<?php echo $this->layout()->droite?> </div>

</div>

<div class="footer">

<?php echo $this->layout()->footer?>

</div>

J'accède à mon objet Layout simplement avec $this->layout() et comme je l'ai dit, l'action principale est rendue dans

l'attribut que j'ai spécifié en configuration, à savoir contenu .Ainsi, si je laisse viewRenderer faire son travail, tout est rendu dans l'attribut de ma layout que j'ai défini. C'est en

fait parce que par défaut le viewRenderer rend la vue correspondant à l'action dispatchée dans le segment 'default'

de l'objet de réponse MVC.

Voila l'astuce: si je rends une action dans un segment autre de l'objet de réponse MVC

(Zend_Controller_Response_Http), alors ce rendu sera accessible dans Zend_Layout via un attribut ayant le nom

du segment de réponse considéré.

Regardez comme j'utilise plusieurs clés: header, droite, gauche et footer. Ainsi, je vais en une seule action rendre

une vue par segment:

Une action qui rend plusieurs vues dans plusieurs segments de la réponse MVC

<?php

class IndexController extends Zend_Controller_Action

{

public function indexAction()

{

$this->view->message = "test de message"; $this->render(); $this->render('header', 'header'); $this->render('droite', 'droite'); $this->render('gauche', 'gauche'); $this->render('footer', 'footer'); }

views/scripts/index/index.phtml

<p>Voici l'affichage de index.phtml avec le message <strong><?php echo $this->message; ?></strong></p>

C'est bien, mais pas optimal car toutes les vues se trouvent dans le même dossier, et bien que seule la vue principale

(index) contienne une variable, elles auraient pu toutes en contenir (les autres scripts de vue ne sont pas montrés).

Une seule action ne peut se contenter de faire le travail pour toutes les vues, c'est en fait une à plusieurs actions

par vue qui doivent être exécutées.

Si je ne remplis aucun attribut de mon layout, alors il n'affiche tout simplement rien (je ne parle donc pas encore

de 'gauche', et 'droite').

II-B - Modèle MVC push

Il est ainsi possible d'utiliser un modèle MVC de type 'push'. Le modèle push possède la particularité d'interdire à

la vue, conceptuellement, d'accéder aux données métier.

Plus simplement: au moment du rendu de la vue, celle-ci doit disposer de toutes les informations dont elle aura besoin

et ne doit en aucun cas aller en chercher elle-même (stratégie MVC 'pull').

J'aime ce type d'architecture MVC: elle est plus contraignante, mais plus découplée: nous avons 3 couches réellement

identifiées, testables et réutilisables, puis toutes les actions vont hériter d'un mode de traitement commun.

Cependant on voit bien que dans la méthode que j'ai utilisée, ca n'est pas top. Il est mieux de bien séparer les

traitements, et de faire confiance à viewRenderer (tant qu'à faire).Ainsi, il faut construire les autres actions (correspondant à header, footer, etc... ), et j'ai plusieurs méthodes pour

le faire.













http://julien-pauli.developpez.com/tutoriels/php/mvc-controleur/












Je pourrai faire une suite de _forward(), seulement dès que je veux changer mon processus: c'est galère, et pour

les architectures complexes, il peut facilement y avoir des dizaines de _forward(), difficilement maintenable...
















II-B-1 - Couple plugin/aide d'action: ActionStack

Un nouveau couple aide d'action/plugin entre alors en jeu pour résoudre ce problème: ActionStack. Il permet une

gestion de pile d'actions (LIFO), et si chacune rend une vue dans un segment différent, je récupère le tout dans ma

layout, et c'est gagné. Voyons ca:

Configurons ActionStack en bootstrap

<?php

class Bootstrap extends Zend_Application_Bootstrap_Bootstrap

{

protected function _initActionStack()

{

$actionStack = Zend_Controller_Action_HelperBroker ::getStaticHelper('actionStack');

$actionStack->actionToStack(new Zend_Controller_Request_Simple( 'footer', 'index'));

$actionStack->actionToStack(new Zend_Controller_Request_Simple( 'header', 'index'));

return $actionStack; // bonne pratique de bootstrap, si je veux récupérer l'objet plus tard }}

IndexController

<?php

class IndexController extends Zend_Controller_Action

{

public function indexAction()

{

$this->view->message = "test de message"; }

public function headerAction()

{

$this->_helper->viewRenderer->setResponseSegment('header'); }

public function footerAction()

{

$this->view->titre = 'Atelier Zend_Layout'; $this->_helper->viewRenderer->setResponseSegment('footer'); }

}

Je récupère en bootstrap l'aide d'action actionStack et je lui ajoute 2 requêtes à dépiler:

IndexController::headerAction() et IndexController::footerAction(). Ordre LIFO je répète: header sera exécuté en

premier.

Tout ceci sera exécuté après mon action principale, actionStack agit sur l'évènement 'postdispatch' et avant le plugin

de Zend_Layout, qui n'intervient qu'à la fin de toutes les requêtes.

Chaque action que vous voyez utilise ce dont elle a besoin (cas minimaliste pour l'exemple), pour ensuite se rendre

chacune dans son segment de réponse (grâce au viewRenderer). Je vous laisse factoriser le comportement si besoin

(c'est largement faisable).

On notera que la vue du footer utilise une variable, le traitement se fait bien dans l'action (même si ici le traitement

est quasi nul, pour l'exemple), action qui passe à la vue son résultat.

Ici, j'ai décidé d'utiliser l'actionStack en bootstrap, rien ne vous empêche de l'utiliser où vous voulez dans votre logique

contrôleur.

La théorie est simple :

L'aide d'action Zend_Controller_Action_Helper_ActionStack enregistre le plugin MVC dès sa création, et permet

de le piloter dans une action (via $this->_helper_actionStack donc).

Le plugin Zend_Controller_Plugin_ActionStack est automatiquement ajouté à la pile de plugin par l'aide d'action,

en place 97, donc avant le plugin qui rend les layouts, et il propose des méthodes pour modifier la pile : popStack();

pushStack(), getStack().













Ca semble très cool, mais ActionStack peut vous jouer des tours. Pensez à tout: si dansune action en plein de milieu de la pile, u ne exception est levée? Si j'utilise une redirectionHTTP? Le casse-tête est proche, mais il trouve des solutions.

II-B-2 - Aide de vue 'action'

Autre méthode: intégrer le rendu de la vue header et footer, dans le template directement. Je rappelle au passage

que le fichier de template, bien qu'utilisé par Zend_Layout, demeure rendu par Zend_View: toutes les méthodes

de Zend_View y existent.

Nous ne pouvons pas utiliser $this->render() (ou $this->partial()): la vue serait alors rendue hors contexte MVC, si

elle a besoin de variables, elle va devoir les chercher elle même: banni dans notre cas de modèle 'push'.

Nous pouvons nous reposer sur l'aide $this->action(), voyons cela:

script de layout retouché (et écourté)

<div class="header">

<?php echo $this->layout()->header ?>

</div><div class="main">

<div class="gauche">

<?php echo $this->action('gauche','login') ?>

</div>

...

Lorsque le template est rendu, action() va lancer une instance clonée du modèle MVC en cours d'exécution, pour

exécuter en parallèle l'action demandée, sur le contrôleur demandé (et le module: facultatif).

Le rendu de la réponse de cette action est alors retourné. Si l'action demande une redirection, celle-ci n'est pas suivie

et rien n'est retourné.

Ainsi, ceci peut être pratique pour les petits rendus, par exemple: un formulaire d'authentification.

Sur le papier c'est bien, mais action() est très gourmande en performance car elle vacloner une grande partie des objets M VC et donc manger beaucoup de mémoire et de processeur. A ce titre, elle est fortement déconseillée d'utilisation, surtout intensive. Aussi, vous êtes sur une instance clonée: pensez parallèle, l'action demandée utiliserad'autres objets de requête, réponse, dispatching, et rendu de vue; que ceux utilisés dansle processus principal.















III - Conclusion

Diagramme de séquence simplifié

Cette maigre application a eu pour but de vous faire comprendre le pattern utilisé par #Zend_Layout, et son

fonctionnement global.

Zend Framework nous présente une solution de templating toute prête et fléxible, en témoignent les méthodes comme

setLayoutPath(), setPluginClass(), setHelperClass(), setView().De la même manière, je n'ai pas traité le cas mais #Zend_Layout peut être utilisé sans la partie MVC, et elle n'est

pas activé par défaut dans MVC, qui peut donc aussi être utilisé sans #Zend_Layout.

Utilisation de l'aide d'action ViewRenderer

Lumière sur les plugins et aides d'action du système MVC

Gestion des exceptions dans MVC : le plugin ErrorHandler


http://julien-pauli.developpez.com/tutoriels/zend-framework/atelier/mvc-exceptions2/

http://julien-pauli.developpez.com/tutoriels/zend-framework/atelier/mvc-plugins-actionhelpers/







Atelierzf Zend Layout

Documents

Transcript of Atelierzf Zend Layout