Mirmo Dynamics - Tag - MVC

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 !

Howto: Utiliser Zend_Controller_RewriteRouter avec Zend_Config

Geoffrey — Tue, 31 Oct 2006 20:26:00 +0100

Comme je le disais plus bas, le Zend Framework Preview 0.2.0 est dans les bacs ! Cette nouvelle mouture apporte son lot de nouveautés, et nous allons nous pencher sur une des plus interressantes: le RewriteRouter. Le RewriteRouter est un routeur pour le composant MVC du Zend Framework qui va nous permettre de configurer nos URL comme dans Ruby on Rails, c'est à dire (en gros), via un fichier de configuration, et c'est là que Zend_Config entre en jeu.

Mettre en place le routeur

C'est bien beau tout ça, mais pour l'utiliser, il faut déjà en informer le controlleur. Pour cela, rien de plus simple, on utilise la méthode addRouter:

$router = new Zend_Controller_RewriteRouter;
$controller = Zend_Controller_Front::getInstance();
$controller->setRouter($router);

Le RewriteRouter est pré-configuré avec deux routes qui permettent d'assurer la compatibilité descendante avec l'ancien routeur, donc jusque là, tout va bien.

Déclarer les routes

Nous utiliserons un fichier de configuration dédié aux routes, que nous appellerons sobrement routes.ini, et que nous placerons dans app/, à coté de son compagnon config.ini. Ce fichier de configuration contiendra une unique section [routes], qui contiendra à son tour les multiples définitions de routes que nous souhaitons y caser. Une route se compose de 5 éléments principaux:

L'identifiant de la route. C'est un identifiant interne utilisé par le RewriteRouter,
l'URL de la route, c'est ce qui permet au routeur de reconnaitre la route à utiliser,
les valeurs par défauts des variables,
les requirements de la route, qui permettent de déterminer si une route est bien formée ou non.

Sans plus attendre, un petit exemple: la route qui pourrait permettre d'accéder à un billet dans dotclear 2:

post.route = post/:year/:month/:day/:title
post.reqs.year = "\d+"
post.reqs.month = "\d+"
post.reqs.day = "\d+"
post.reqs.title = "[a-zA-Z0-9_:-]"+
post.defaults.controller = post
post.defaults.action = view
post.defaults.title =

Elle pourrait seulement, car en fait, la regexp du title est trop restrictive (une URL peut contenir d'autres caractères que ceux là), et de plus, les URL stockées par dotclear 2 en base de données comprennent tout ce qui se trouve après post/ (par exemple le champs post_url de ce billet contient: 2006/10/31/Howto:-Utiliser-Zend_Controller_RewriteRouter-avec-Zend_Config).

Cela étant dit, la route que nous venons de décrire s'appliquera aux URLs suivantes:

/post/2006/30/10/ZendFramework
/post/42/2006/56/Foobar
/post/2006/30/10/
etc.

Mais pas à:

/post/2006/Foobar
/post/Foobar/2006/30/01
etc.

On note donc d'ores et déjà:

que la validation des composants d'une route se fait par expression régulière
qu'on peut ommettre le dernier composant d'une route si il possède une valeur par défaut (récursivement)
qu'on ne peut pas modifier l'ordre des composants d'une route
qu'on doit spécifier manuellement le nom du controlleur et de l'action à utiliser
et c'est déjà pas mal.

Décortiquons maintenant une URL: /post/2006/30/10/ZendFramework. Le routeur va diviser cette URL ainsi:

Controller: post (d'après les defaults)
Action: view (d'après les defaults)
Paramètres: year: 2006, month: 30, day: 10, title: ZendFramework (d'après l'URL)

Les paramètres ainsi détectés seront disponibles via la méthode $this->_getParam($name); a l'intérieur du controlleur.

Dernier point de ce chapitre, une déclaration de route peut comporter deux variables spéciales: :controller et :action, qui servent respectivement à détecter le controller et l'action à utiliser dans l'url. Par exemple, la route builtin compat chargé d'assurer la compatibilité descendante se déclare ainsi:

compat.route = :controller/:action
compat.defaults.controller = index
compat.defaults.action = index

Assembler le tout

Dernière étape, transférer directement toutes ces déclarations dans le Routeur: n'y allons pas par quatre chemin:

$router->addConfig(new Zend_Config_Ini('/path/to/routes.ini', null), 'routes');

C'est aussi simple que ça. Ce qui nous donne, en prenant en compte le morceau de code du début de l'article:

$router = new Zend_Controller_RewriteRouter;
$router->addConfig(new Zend_Config_Ini($routes_path, null), 'routes');
$controller = Zend_Controller_Front::getInstance();
$controller->setRouter($router);

And voilà. Je ne saurais que vous conseiller la lecture du manuel pour plus d'informations (sachant qu'en fait, addRoute attend en deuxième argument une instance de Zend_Controller_Router_Route, mais qui s'instancie avec les paramètres qu'ils passent à addRoute, petite coquille du manuel :p).

Automatisation des vues

Geoffrey — Wed, 30 Aug 2006 13:17:00 +0200

Le rebutement principal que j'ai eu au début avec le Zend Framework était l'impossibilité (a priori) d'automatiser le rendu des vues en fonction du controlleur et de l'action appelés. Mes pérénigrations webesques m'ont finalement fait entrevoir la solution.

EDIT: mes nouvelles pérégrinations dans les sources du Zend Framework m'ont fait entrevoir une meilleure solution :-)

Tout se passe dans le destructeur du controlleur, et nous allons voir ici une version édulcorée de celle disponible dans le lien sus-cité. L'astuce qui sauve, c'est de savoir que l'objet Controller possède un membre _action, qui lui même propose (entre autres) deux méthodes bien utiles: getControllerName et getActionName. Il suffit donc de récupérer ces informations pour construire dynamiquement le chemin de la vue à utiliser pour un controlleur donné:

abstract class My_Controller_Action extends Zend_Controller_Action {
	public function __destruct() {
		$view = Zend::registry('view');
		$controller = $this->_action->getControllerName();
		$action = $this->_action->getActionName();
		$viewPath = sprintf('%s/%s.php', $controller, $action);
		try {
			echo $view->render($viewPath);
		} catch (Exception $e) {
			trigger_error('Unable to render view: ' . $e->getMessage(), E_USER_ERROR);
		}
	}
}

Fichier source

Ce controlleur requiert que vous ayez instancié, configuré et enregistré Zend_View au préalable. Il ira, lors de sa destruction, chercher la vue dont le nom correspond à controller/action.php, c'est à dire:

pour une URL du type http://example.com/foo/bar/, foo/bar.php,
pour http://example.com/, index/index.php,
pour http://example.com/foo/, foo/index.php.

Pour une raison obscure, on ne peut pas laisser trainer l'éventuelle exception générée par Zend_View dans le cas d'une vue inexistante. Cela entre en conflit avec une autre Exception qui traine, j'essayerai de tirer ça au clair :-)