Un petit dessin valant mieux qu'un long discours, entrons dans le vif du sujet. On assume ici un environnement préinstallé: Apache / PHP5 / MySQL, avec une copie du Zend Framework dans /usr/share/zend/, ainsi que le .htaccess suivant à la racine de votre site:

RewriteEnfine On
RewriteRule !\.(js|ico|gif|jpg|png|css)$ index.php

Commençons par le commencement...

index.php

ini_set('include_path', ini_get('include_path').':/usr/share/zend/library/');
 
include('Zend.php');
 
Zend::loadClass('Zend_Controller_Action');
Zend::loadClass('Zend_Controller_Front');
Zend::loadClass('Zend_View');
 
$controller = Zend_Controller_Front::getInstance();
$controller->setControllerDirectory(dirname(__FILE__) . '/controllers/');
 
$view = new Zend_View;
$view->setScriptPath(dirname(__FILE__) . '/views/');
 
Zend::register('view', $view);
 
try {
 
    $controller->dispatch();
 
} catch (Zend_Exception $e) {
 
    die($e->getMEssage());
 
}

On peut distinguer trois grandes étapes:

  1. Mise en place de l'environnement (pas grand chose à dire la dessus)
  2. Mise en place des objets
  3. Dispatch

La mise en place des objets est on ne peut plus claire. On configure le front controller (Zend_Controller_Front) pour lui dire où trouver les controllers, puis on configure les vues (Zend_View) pour leur dire où trouver... les vues :-) On enregistre ensuite l'objet $view dans le registre, qui n'est rien de plus qu'un endroit pratique où stocker des objets/données pour y avoir accès plus tard (Zend::register($name, $value) et $var = Zend::registry($name);).

Dernière étape, le dispatch, qui utilise les objets Zend_Controller_Router et Zend_Controller_Dispatcher. Ces deux objets sont au coeur du processus de sélection du controller à executer. Le Router va déterminer, à partir de l'environnement (en général l'URL, via $_SERVER['REQUEST_URI'] par exemple) quelle action executer et dans quel controller, tandis que le Dispatcher va s'occuper lui de les trouver (par exemple dire FooController::bar(), dans controllers/FooController.php).

Le Zend Framework gère en natif les friendly urls, et ça c'est chouette. Par exemple: les urls suivantes:

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

Seront analysées comme suit par le Routeur par défaut:

  • controller: foo, action: bar
  • controller: foo, action: index
  • controller: index, action: index

Dernières choses à savoir sur la théorie:

  • quand le controlleur est défini par l'url mais non trouvé par le Dispatcher, celui ci execute index/noRoute.
  • les controllers sont des classes qui étendent Zend_Controller_Action
  • le Dispatcher par défaut va executer(en supposant une url type http://example.org/foo/bar) FooController::barAction dans FooController.php (modulo le path déterminé avec Zend_Controller_Front::setControllerPath)

controllers/IndexController.php

class IndexController extends Zend_Controller_Action {
 
    public function indexAction() {
 
        echo 'Hello, world !';
 
    }
 
    public function noRouteAction() {
 
        echo 'La page demandée n\'existe pas';
 
    }
 
}

Nous voilà avec un Hello, world ! fonctionnel !

Dernier point de cette brève excursion dans le Zend Framework, les vues. Pas grand chose à en dire pour le moment, si ce n'est que par défaut l'objet Zend_View se contente d'include() les fichiers templates.

controllers/FooController.php

class FooController extends Zend_Controller_Action {
 
    public function indexAction() {
 
        echo 'Nothing to see here';
 
    }
 
    public function barAction() {
 
        $view = Zend::registry('view');
        $view->render('fooBar.php');
 
    }
 
}

Pas grand chose à dire la non plus, on récupère l'objet $view via Zend::registry, et on lui demande d'executer la vue fooBar.php. C'est une application très basique du système de vue, mais il est possible en théorie de lui interfacer virtuellement n'importe quel moteur de template. Le seul vrai problème que j'ai rencontré pour ma part (étant donné que je n'aime pas les moteurs de template de toute façon), c'est l'impossibilité (a priori, et pour l'instant) de récupéré via le front controller (ou n'importe quel autre objet public) le nom du controller et de l'action en cours, pour pouvoir executer quelque chose du genre:

$view->render("{$controller}/{$action}.php");

Ce qui, AMHA, simplifierai énormément la tache :-) Cela dit, n'oublions pas que ce framework n'est pas encore en version finale, donc stay tuned comme on dit.

Pour en revenir au titre du billet, Zend Framework est-il le futur de PHP ? Je pense qu'on peut raisonnablement le penser oui. Implémenter un framework complet, cohérent et puissant n'est pas à la portée de tout le monde, et même si de nombreux efforts ont été faits dans ce sens, rien de probant n'a jamais vu le jour jusqu'à aujourd'hui. Je pense vraiment que l'approche du Zend Framework permettra une plus grande expansion de PHP dans les milieux professionnels, et d'autant plus avec PHP6 (mais là je m'avance peut-être un peu trop dans le temps).

Le mot de la fin, ressources supplémentaires sur Zend Framework: