Atelierzf Zend Layout

Atelier Zend Framework: Introduction au templating avec Zend_Layout
par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)
Date de publication : 21/01/2008 Dernire mise jour : 07/12/2010
L'intgration et l'utilisation de template sont indispensables sur le web. #Zend_Layout est le composant natif de Zend Framework qui reprsente une solution flexible d'intgration de vues. Voyons ensemble quoi ressemble #Zend_Layout et introduisons aussi quelques autres composants qui s'interconnectent bien ensemble. Nous allons dcrire quelques utilisations possibles, allant du fonctionnement des layouts, jusqu' l'application d'une approche MVC dite 'push'.
Atelier Zend Framework: Introduction au templating avec Zend_Layout par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)
I - Zend_Layout: dfinition et buts.............................................................................................................................. 3 I-A - Principe...........................................................................................................................................................3 I-B - Configuration.................................................................................................................................................. 3 II - Intgration dans le modle MVC........................................................................................................................... 5 II-A - Le fichier de template................................................................................................................................... 6 II-B - Modle MVC push........................................................................................................................................ 7 II-B-1 - Couple plugin/aide d'action: ActionStack............................................................................................. 9 II-B-2 - Aide de vue 'action'............................................................................................................................ 10 III - Conclusion...........................................................................................................................................................11
-2Copyright 2007 - Julien Pauli. Aucune reproduction, mme 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 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/zend-framework/atelier/zend-layout/
I - Zend_Layout: dfinition 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'intgrer des vues, dans des vues. Comme son habitude, Zend Framework offre une flexibilit trs bonne. Le composant #Zend_Layout est livr avec une configuration de base, mais il est apprciable de noter qu'elle est compltement personnalisable. Les services de #Zend_Layout son multiples (et surtout utilis dans un cadre MVC) : 1 2 3 Rendre automatiquement un ou des templates (un template est une vue contenant d'autres morceaux de vues) ; Fournir un moyen de configurer l'objet Layout (nom des templates, chemins...), par dfaut il suit les mmes rgles que l'objet ViewRenderer ; Permettre une approche utilisant le modle MVC de ZF, ou pas (indpendance).
#Zend_Layout apporte une solution native lgante au problme 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 rsum ici. Nous savons que par dfaut, grce 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 intgr dans une vue de plus haut niveau, appele Layout, ou template (on peut jouer sur les mots). C'est le principe de la vue en 2 temps : 1 2 On rend la vue dsire, en gnral grce ViewRenderer (automatique : correspond l'action dispatche) ; On rend un layout, dans lequel va tre intgre la vue prcdemment rendue, ainsi qu'ventuellement, d'autres vues, issues ventuellement aussi, d'autres actions parallles.
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 frquent 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 2 3 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 dfaut: layout.phtml ; Le chemin d'accs aux fichiers de templates, nous avons dit que dans cet atelier nous n'aurons qu'un seul template (cl de configuration layoutPath, valeur par dfaut: chemin du script de vue courant) ; L'attribut de l'objet layout qui contiendra la vue actuellement rendue par le processus MVC (vue principale) (cl de configuration contentKey, valeur par dfaut: content)
Accessoirement, il est possible de configurer d'autres paramtres relatifs la personnalisation du rendu du layout. Zend_Layout est configurable de diffrente manire, compatible avec Zend_Config et Zend_Application (plugin de ressource). #Zend_Layout fonctionne soit de manire couple au systme MVC de ZF (Zend_Controller_*), soit de manire entirement autonomme.
Pour se lier au modle MVC, #Zend_Layout utilise un couple plugin MVC/aide d'action qui est personnalisable (trs bonne flxibilit). Par dfaut Zend_Layout_Controller_Plugin_Layout et Zend_Layout_Controller_Action_Helper_Layout sont utiliss Nous utiliserons #Zend_Layout dans un contexte MVC dans la suite de cette article.
II - Intgration dans le modle 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 dfaut) :
A premire vue on semble comprendre comment cela fonctionne, mais il y a des astuces au niveau conceptuel bien intgrer: Dja, il faut pouvoir initialiser le Layout. En effet, notre modle MVC n'est pas affect par Zend_Layout, avant qu'on ne le lui spcifie clairement. Ainsi, si vous ne touchez rien, votre application MVC ne va pas utiliser Zend_Layout par dfaut. Pour l'utiliser, Zend_Layout fournit une mthode statique : startMVC(). activation des layouts dans le modle MVC
<?php $config = new Zend_Config_Ini('config.ini'); Zend_Layout::startMvc($config>layout); // activation des layouts, sans a, le modle MVC demeure le mme que celui que vous connaissez // activation de MVC et lancement (dispatch())
config.ini
layout.layout = template layout.contentKey = contenu -5Copyright 2007 - Julien Pauli. Aucune reproduction, mme 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 E de dommages et intrts.
Comme dans tous mes ateliers, j'essaye d'aller droit au but. Ce bootstrap simplifi montre comment lier Zend_Layout au systme 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 dcid que mon fichier de template s'appelle template, il se situe la racine de mon dossier de vue (comportement par dfaut: je n'ai pas spcifi de paramtre layoutPath), et dans ce fichier l'attribut qui me permettra de rendre le contenu de la vue actuellement dispatche s'appelle contenu. Par dfaut, je ne l'ai pas change non plus, l'extension d'un fichier de template est la mme que celle des vues, savoir phtml. La mthode startMVC() effectue plusieurs actions : Elle cre une instance de Zend_Layout, puis elle enregistre le plugin et l'aide d'action prciss (si non prciss, les classes par dfaut cites plus haut seront utilises). Le plugin est enregistr avec un numro de pile de manire ce qu'il soit l'avant dernier intervenir, sur l'vnement MVC postdispatch, le dernier plugin tant errorHandler. Son rle est de prendre la vue rendue automatiquement par viewRenderer, puis de rendre le fichier de template en intgrant le contenu de cette vue dans l'attribut spcial de rendu (dans notre cas: template). Les rles du plugin et de l'aide d'action sont essentiels: L'aide d'action permet de partager l'objet Zend_Layout tout contrleur, ainsi, dans toute action, $this->_helper>layout est l'instance de Zend_Layout utilise dans MVC (et configure en bootstrap). Le plugin va enregistrer un vnement 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'accder 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 mthodes setPluginClass() et setHelperClass(). Vous pouvez aussi passer votre propre objet de vue Zend_Layout, via setView(). Par dfaut Zend_Layout extrait la vue de viewRenderer, vous n'avez donc qu'un objet vue dans tout votre processus, sauf si vous dsirez un comportement alternatif. MVC ou pas, Zend_Layout a besoin d'un objet Zend_View_Interface pour fonctionner, notamment pour rendre le fichier de template.
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 schma ci dessus, qui est un schma 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> -6Copyright 2007 - Julien Pauli. Aucune reproduction, mme 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 E de dommages et intrts.
script de layout
<div class="droite"> <?php echo $this->layout()->droite?> </div> </div> <div class="footer"> <?php echo $this->layout()->footer?> </div>
J'accde mon objet Layout simplement avec $this->layout() et comme je l'ai dit, l'action principale est rendue dans l'attribut que j'ai spcifi en configuration, savoir contenu. Ainsi, si je laisse viewRenderer faire son travail, tout est rendu dans l'attribut de ma layout que j'ai dfini. C'est en fait parce que par dfaut le viewRenderer rend la vue correspondant l'action dispatche dans le segment 'default' de l'objet de rponse MVC. Voila l'astuce: si je rends une action dans un segment autre de l'objet de rponse MVC (Zend_Controller_Response_Http), alors ce rendu sera accessible dans Zend_Layout via un attribut ayant le nom du segment de rponse considr. Regardez comme j'utilise plusieurs cls: 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 rponse 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 mme 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 montrs). 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 excutes. 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 - Modle MVC push

Il est ainsi possible d'utiliser un modle MVC de type 'push'. Le modle push possde la particularit d'interdire la vue, conceptuellement, d'accder aux donnes mtier. 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-mme (stratgie MVC 'pull'). J'aime ce type d'architecture MVC: elle est plus contraignante, mais plus dcouple: nous avons 3 couches rellement identifies, testables et rutilisables, puis toutes les actions vont hriter d'un mode de traitement commun. Cependant on voit bien que dans la mthode que j'ai utilise, ca n'est pas top. Il est mieux de bien sparer 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 mthodes pour le faire.
Je pourrai faire une suite de _forward(), seulement ds que je veux changer mon processus: c'est galre, 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 rsoudre ce problme: ActionStack. Il permet une gestion de pile d'actions (LIFO), et si chacune rend une vue dans un segment diffrent, je rcupre 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 rcuprer 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 rcupre en bootstrap l'aide d'action actionStack et je lui ajoute 2 requtes dpiler: IndexController::headerAction() et IndexController::footerAction(). Ordre LIFO je rpte: header sera excut en premier. Tout ceci sera excut aprs mon action principale, actionStack agit sur l'vnement 'postdispatch' et avant le plugin de Zend_Layout, qui n'intervient qu' la fin de toutes les requtes. 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 rponse (grce 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 (mme si ici le traitement est quasi nul, pour l'exemple), action qui passe la vue son rsultat. Ici, j'ai dcid d'utiliser l'actionStack en bootstrap, rien ne vous empche de l'utiliser o vous voulez dans votre logique contrleur. La thorie est simple : L'aide d'action Zend_Controller_Action_Helper_ActionStack enregistre le plugin MVC ds sa cration, 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 mthodes pour modifier la pile : popStack(); pushStack(), getStack().
Ca semble trs cool, mais ActionStack peut vous jouer des tours. Pensez tout: si dans une action en plein de milieu de la pile, une exception est leve? Si j'utilise une redirection HTTP? Le casse-tte est proche, mais il trouve des solutions.
II-B-2 - Aide de vue 'action'

Autre mthode: intgrer 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 mthodes 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 mme: banni dans notre cas de modle '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 clone du modle MVC en cours d'excution, pour excuter en parallle l'action demande, sur le contrleur demand (et le module: facultatif). Le rendu de la rponse 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 trs gourmande en performance car elle va cloner une grande partie des objets MVC et donc manger beaucoup de mmoire et de processeur. A ce titre, elle est fortement dconseille d'utilisation, surtout intensive. Aussi, vous tes sur une instance clone: pensez parallle, l'action demande utilisera d'autres objets de requte, rponse, dispatching, et rendu de vue; que ceux utiliss dans le processus principal.
- 10 Copyright 2007 - Julien Pauli. Aucune reproduction, mme 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 E de dommages et intrts.
III - Conclusion
Diagramme de squence 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 prsente une solution de templating toute prte et flxible, en tmoignent les mthodes comme setLayoutPath(), setPluginClass(), setHelperClass(), setView(). De la mme manire, je n'ai pas trait le cas mais #Zend_Layout peut tre utilis sans la partie MVC, et elle n'est pas activ par dfaut dans MVC, qui peut donc aussi tre utilis sans #Zend_Layout. Utilisation de l'aide d'action ViewRenderer Lumire sur les plugins et aides d'action du systme MVC Gestion des exceptions dans MVC : le plugin ErrorHandler
- 11 Copyright 2007 - Julien Pauli. Aucune reproduction, mme 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 E de dommages et intrts.

Atelierzf Zend Layout

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Atelierzf Zend Layout

Uploaded by

Copyright:

Available Formats

Atelier Zend Framework: Introduction au templating avec Zend_Layout

I - Zend_Layout: dfinition et buts

II - Intgration dans le modle MVC

II-A - Le fichier de template

II-B - Modle MVC push

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

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

You might also like