Zend Framework: Un plugin simple pour le Front Controller

Geoffrey — Sun, 19 Nov 2006 21:30:00 +0100

L'implémentation du Front Controller du Zend Framework inclue un système bien pratique de plugins, qui va nous permettre de réaliser plus simplement et proprement l'automatisation des vues, initialement embarquée dans une extension de Zend_Controller_Action (ce qui pose quelques problèmes, nottament au lors de l'utilisation de __forward() et _redirect()).

Techniquement, un plugin est une classe qui implémente l'interface des plugins (Zend_Controller_Plugin_Interface). Dans la pratique, une classe abstraite est fournie pour simplifier la tache (Zend_Controller_Plugin_Abstract). Notre premier plugin s'appellera AutoView (My_Controller_Plugin_AutoView, stocké dans My/Controller/Plugin/AutoView.php).

Un plugin est donc une classe dont les méthodes seront appelées a différents moments de la dispatch loop du controlleur frontal, comme on peut le voir dans Zend_Controller_Front::dispatch():

routeStartup(), à la mise en route du routeur
routeShutdown($action), à l'arrêt du routeur
dispatchLoopStartup($action), avant la dispatch loop
preDispatch($action), avant d'executer une action
postDispatch($action), après avoir executé une action
dispatchLoopShutdown(), pour finir.

A chaud, on pourrait se dire que postDispatch est exactement ce dont on n'a besoin, et on se tromperait. Ce qu'il faut savoir, c'est que l'argument $action passé à postDispatch contient l'action qui suit celle qui vient d'être executé. Dans la majorité des cas, n'ayant qu'une seule action à executer, $action sera vide, et on se retrouve l'air un peu con.

Bon donc, on va user d'un stratagème: notre plugin va stocker les actions qui passent dans preDispatch, pour s'occuper de la dernière à être passée dans dispatchLoopShutdown. Dernier détail, notre plugin s'occupera lui même de gérer son instance de Zend_View. Et sans plus attendre, le code, qui n'a finalement rien de compliqué:

<?php

require_once 'Zend/Controller/Plugin/Abstract.php';

class My_Controller_Plugin_AutoView extends Zend_Controller_Plugin_Abstract {

	private $_lastAction;

	public function __construct() {
		$view = new Zend_View;
		$view->setScriptPath(APP_ROOT.'/views/');
		Zend::register('view', $view);
	}

	public function preDispatch($action) {
		$this->_lastAction = clone($action);
		return $action;
	}

	public function dispatchLoopShutdown() {
		if (!is_null($this->_lastAction)) {
			$viewPath = sprintf('%s/%s.php', $this->_lastAction->getControllerName(), $this->_lastAction->getActionName());
			echo Zend::registry('view')->render($viewPath);
		}
	}
}

?>

Bien, notre plugin vaillament codé, il nous faut désormais expliquer au controlleur frontal qu'on aimerai bien qu'il en tienne compte. Cela se passe fort logiquement dans le bootstrap, via la méthode registerPlugin du sus-cité controlleur frontal, qui prend en argument une instance d'un objet implémentant Zend_Controller_Plugin_Interface:

$controller = Zend_Controller_Front::getInstance();
$controller->registerPlugin(new My_Controller_Plugin_AutoView);

And viola !

Débuter un projet: un brin d'organisation

Geoffrey — Sat, 16 Sep 2006 13:05:00 +0200

Architecture des dossiers

Commençons par le commencement: le stockage des fichiers. Pour ne pas trébucher sur la longue route que représente l'accomplissement d'un projet, il convient de bien s'organiser dès le début, et savoir précisément où stocker et trouver les choses est une bonne chose. Nous allons donc nous baser sur les recommandations de Zend à ce sujet:

monprojet/
     app/
          controllers/
          models/
          views/
     library/
     www/

A partir de là, on peut faire évoluer un peu. J'ai personellement rajouté un répertoire dist/, qui contient les scripts nécessaire à la distribution de mon application (dump des bases SQL par exemple), et cet article de Rob parle de répertoires comme scripts/ (pour contenir les scripts cron par exemple) et tmp/ (à toutes fins utiles).

Enfin, notons l'utilité d'un répertoire library/ext/ ou assimilé, comme expliqué ici.

Définir ses controlleurs et ses vues

Première question a se poser: qu'est-ce qu'un controlleur ? Un controlleur, c'est tout simplement une entité qui va s'occuper de traiter une requête que reçoit l'application. Dans le Zend Framework, les controlleurs possèdent des Actions (sous formes de méthodes), qui permettent d'avoir des URL telles que:

http://example.com/foo/bar/

Dans un tel cas de figure, Zend Framework ira chercher la méthode barAction du controlleur fooController. On voit dès l'ors l'interet de bien définir nos besoins en termes de controlleurs dès maintenant, puisque c'est cela qui définira toute l'architecture de l'application. La marche à suivre est la suivante:

Lister toutes les fonctionnalitées de l'application
Les regrouper logiquement
Traduire tout ça en termes de controlleurs et d'action

Prenons l'exemple typique d'un portail d'actualité. Voici quelques unes des actions que nous serons susceptibles de proposer:

Ajouter une news
Lister des news (action par défaut)
Voir les détails d'une news
Ajouter un commentaire

Ce qui se traduit par:

controlleur News
- action Ajouter (url: news/ajouter/)
- action Lister (url: news/lister/)
- action Voir (url: news/voir/id/$id)
controlleur Commentaires
- action Ajouter (url: commentaires/ajouter/news/$id)

Cela nous permet donc de prévoir l'arborescence suivante:

app/
        controllers/
                CommentairesController.php
                IndexController.php
                NewsController.php
        views/
                Commentaires/
                        ajouter.php
                Index/
                        index.php
                News/
                        ajouter.php
                        lister.php
                        voir.php

Voilà pour la théorie, pour la pratique, il faut mettre en place un environnement d'execution dans lequel on pourra déployer toutes la puissance du Zend Framework, c'est ce que nous verrons la prochaine fois :-)

Mirmo Dynamics - Tag - vues

Zend Framework: Un plugin simple pour le Front Controller

Débuter un projet: un brin d'organisation

Architecture des dossiers

Définir ses controlleurs et ses vues