20.Archives

20.4.Zend Framework

20.4.1.Introduction

Zend framework est le framework proposé par Zend (auteur du moteur de PHP). Ce framework implémente le modèle MVC et propose toute une palette de fonctions destinées à faciliter les développements. Il peut donc être utilisé soit en tant que simple bibliothèque de fonctions soit en tant que "moteur" MVC.

20.4.2.Installation

20.4.2.1.Copie de Zend Framework

Pour simplifier les explications nous supposons que le nom du répertoire où vous déposez vos scripts (i.e. votre espace web[où?]) est www/ (sinon, vous devrez adapter les informations données en conséquence).
Commencer par télécharger Zend framework à l'adresse http://www.zend.com/fr/community/downloads. Puis décompressez l'archive dans un répertoire quelconque de préférence hors de votre espace web (i.e. soit au même niveau que www/, soit carrément dans un espace dédié ex: /var/php/libs/).
Ce qui nous intéresse c'est le répertoire library/. Si jamais vous êtes contraint de mettre la bibliothèque Zend dans votre espace web (www/) vous pouvez ne copier que library/ et le renommer en ZendFramework, de sorte a avoir l'un des arborescences suivantes:
  • ...
    • www/
  • ...
    • ZendFramework/
      • library/
        • Zend/
          • Acl/
          • Auth/
          • ...
          • Wildfire/
          • XmlRpc/
  • ...
    • www/
      • ZendFramework/
        • Zend/
          • Acl/
          • Auth/
          • ...
          • Wildfire/
          • XmlRpc/
Vous devrez ensuite ajouter le dossier contenant Zend/ à l'include_path[c'est quoi?].
Pour une installation de Zend Framework en tant que simple bibliothèque l'installation s'arrête là.

20.4.2.2.Installation en tant que "moteur" MVC

Nous supposerons que vous disposez d'un serveur Apache et que le module mod_rewrite a été activé (si vous ne savez pas si c'est le cas, vous le découvrirez très vite).

20.4.2.3.Configuration et test du module mod_rewrite

Sous le répertoire www/ créez un fichier .htaccess avec le contenu suivant:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ /index.php5 [NC,L]
Ainsi que le fichier index.php5 suivant
<?php
echo 'Avec mod_rewrite, les requetes passent par ici';
?>
Maintenant tapez n'importe quelle URL (n'existant à priori pas) de ce site web (ex: http://localhost/test_mod_rewrite). Bien, que le fichier test_mod_rewrite n'existe pas vous devez voir le message Avec mod_rewrite, la plupart des requetes passent par ici apparaître. Si à la place, vous obtenez un message d'erreur "500, Internal server error" c'est probablement que le module mod_rewrite n'est pas activé (à condition que votre fichier .htaccess soit correct). Malheureusement, pour traiter les différents cas de figure, il faudrait un chapitre complet pour préciser comment activer le mod_rewrite (ce n'est pas l'objet de ce chapitre).
rem
  • Nous supposons ici que les scripts PHP 5 sont associés à l'extension .php5 ainsi le script à l'adresse http://localhost/index.php5 doit être interprété (i.e. on ne doit pas voir le code php comme "echo"). Si ce n'est pas le cas, remplacer l'extension .php5 par .php aussi bien dans le nom du fichier que dans le fichier .htaccess

20.4.2.4.Mise en place

Maintenant que vous vous êtes assurés que les règles de mod_rewrite fonctionnent, remplacer le fichier index.php5 par le suivant:
<?php
set_include_path(dirname(__FILE__)."/../ZendFramework".PATH_SEPARATOR.
                 get_include_path());

require_once("Zend/Loader.php");
Zend_Loader::registerAutoLoad();

try {
    require(dirname(__FILE__)."/../app/amorce.php");
} catch (Exception $e) {
    die("Cette page ne peut être exécutée");
}

Zend_Controller_Front::getInstance()->dispatch();
Dans le même répertoire que celui qui contient www/ et ZendFramework/, créez un répertoire app/. C'est ce répertoire qui contiendra véritablement les scripts de votre application. Commençez par y copier le fichier amorce.php suivant:
<?php
$frontController = Zend_Controller_Front::getInstance();
$frontController->setControllerDirectory(dirname(__FILE__)."/controllers");

unset($frontController);
?>
Nous n'allons pas nous égarer en expliquant maintenant le rôle de ces fichiers. Peut-être y reviendrons nous plus tard mais pour le moment considérez simplement qu'ils font partie de l'installation.

20.4.3.Controleur et vue

20.4.3.1.Introduction

Les scripts précédents permettent d'initialiser le controleur frontal (front controller). Autrement dit le module qui fait le lien entre l'URL appellée et le code a exécuter. Les urls ayant le format suivant http://<nom du serveur>/controleur/action, le controleur frontal va rechercher quelle classe implémente le controleur (ou module) appelé, puis appelle la méthode associée à l'action demandée.
Ainsi dans le cas http://localhost/bienvenue/affiche, le controleur est bienvenue et l'action affiche.
L'implémentation du controleur se fait en créant une classe dérivant de la classe Zend_Controller_Action, que l'on baptisera du nom du controleur (tel qu'il apparaît dans l'URL) avec le suffixe Controller (ex: BienvenueController) et que l'on sauvera dans un répertoire controllers/ sous app/ (tel que nous l'avions précisé dans le fichier amorce.php).
Cette classe doit alors contenir une méthode au nom composé du nom de l'action avec le suffix Action (ex: afficheAction).
rem
  • Si l'URL ne précise pas de nom d'action alors l'action appelée sera l'action index (i.e. la méthode indexAction())
  • Si l'URL ne précise pas de nom de controleur alors le controleur appelé sera le controleur index (i.e. la classe IndexController)

20.4.3.2.Implémentation du controleur

<?php
class BienvenueController extends Zend_Controller_Action
{
    public function afficheAction()
    {
    }
}
Comme vous pouvez le deviner, ce controleur ne fait pas grand chose... et pourtant... ce n'est pas pour cela qu'il ne fait rien. Si vous testez maintenant votre application vous obtiendrez un message d'erreur retourné par le framework Zend. En effet, la méthode afficheAction() est bien executée (même si ça ne fait rien) puis, automatiquement (par défaut) la vue associée à cette action est appelée. Il nous faut donc l'implémenter.

20.4.3.3.Implémentation de la vue

Par défaut à chaque action de chaque controleur est associée une vue. Cette vue doit être définie (par défaut) dans le fichier views/scripts/<nom du controleur>/<nom de l'action>.phtml sous app/. Vous pouvez donc créer le fichier app/views/scripts/bienvenue/affiche.phtml suivant:
Bienvenue !

20.4.3.4.Test

Il suffit d'appeler l'URL http://localhost/bienvenue/affiche pour voir le message de bienvenue s'afficher. Si tel est bien le cas, vous êtes prêt pour découvrir enfin véritablement toute la magie de ce framework.

20.4.4.Formulaire

20.4.4.1.La classe du formulaire

Cette fois-ci nous allons créer un formulaire en nous appuyant sur une nouvelle classe du framework Zend_Form.
<?php
class MonformForm extends Zend_Form
{
    public function init()
    {
        $this->setMethod('post');

        $this->addElement('text', 'nom',
                          array('label' => 'Nom:',
                                'required' => true)
                         );
        $this->addElement('submit', 'submit', array('label' => 'Enregistrer'));
    }
}
Vous pouvez copier ce fichier un peu où bon vous semble mais le copier dans un repertoire forms/ sous app/ est sans doute le plus judicieux (c'est ce que nous avons retenu en tout cas).
Le contenu de ce fichier est assez simple à comprendre. Nous créons une instance de formulaire, s'appuyant sur la méthode POST, incluant un champ de type texte, avec pour identifiant "nom", pour label "Nom:" et il s'agit d'un champ obligatoire. Ce formulaire est en outre muni d'un bouton submit avec un label "Enregistrer".

20.4.4.2.Le controleur du formulaire

Comme nous l'avons vu précédemment, par défaut, à tout controleur est associé une vue. Et il se trouve que l'objet représentant cette vue est disponible au sein de l'objet controleur via la variable $this->view. Nous pouvons alors associer une instance du formulaire (précédent) à cette vue. C'est ce que fait le code suivant:
<?php
require_once(dirname(__FILE__)."/../forms/MonformForm.php");

class MonformController extends Zend_Controller_Action
{
    public function indexAction()
    {
         $this->view->form = new MonformForm();
    }
}

20.4.4.3.La vue du formulaire

Reste à créer la vue (ou son template). A copier évidemment sous /apps/views/scripts/monform/.
Mon 1er formulaire Zend
<?php echo $this->form ?>

20.4.4.4.Test

Maintenant, il suffit d'appeler l'URL http://localhost/monform pour observer le résultat. Le formulaire s'affiche sans même avoir à écrire le moindre bout de code HTML. Voilà, ce dont j'ai toujours rêvé.
Certes la présentation est sommaire mais peut-être suffisante pour faire une maquette du projet à venir, que l'on n'aura même pas besoin de jeter, sachant qu'il sera par la suite possible de personnaliser le rendu pour le rendre plus... sexy.
Cependant, dans l'immédiat, il y a plus important, puisque la validation du formulaire n'est pas effective (que l'on saisisse ou non un nom, le résultat est le même alors qu'il s'agit d'un champ obligatoire).

20.4.5.Validation du formulaire

Pour valider les données du formulaire, nous devons compléter l'implémentation du controleur en nous appuyant sur les méthodes de la classe Zend_Form (dont hérite notre formulaire).
<?php
require_once(dirname(__FILE__)."/../forms/MonformForm.php");

class MonformController extends Zend_Controller_Action
{
    public function indexAction()
    {
         $form = new MonformForm();

         // Si le formulaire vient d'être "soumis"
         // nous aurons besoins des données suivantes
         $request = $this->getRequest();

         // Justement... voyons si le formulaire vient d'être "posté"
         if ($request->isPost()) {
             // Oui... alors validons les données saisies.
             if ($form->isValid($request->getPost())) {
                // Tout est valide... 
                // Nous pouvons sauver les données (non implémenté ici)
                // Puis passer à la vue "sauve"
                return $this->_helper->redirector('sauve');
             }
         }
 
         $this->view->form = $form;
    }

    public function sauveAction()
    {
    }
}
Tout d'abord il convient de récupérer les données de la requête afin de vérifier si un formulaire a été soumis (via la méthode POST). Si tel est le cas, il est alors facile de valider les données (ici, s'assurer que le champ obligatoire nom est saisie) simplement en appelant la méthode isValid() de l'objet formulaire avec pour paramètre ceux de la requête (récupérés via $this->getRequest()->getPost()). A ce niveau il y a 2 cas de figures possibles:
  • La validation est un succés, nous pouvons alors sauvegarder (ce qui n'est pas fait ici) et nous rediriger vers une nouvelle action/vue
  • La validation échoue, et alors de façon transparente une liste de messages d'erreur associés à la validation des différents champs est construite et sera automatiquement affichée (en utilisant exactement le même template de vue que précédemment)
Testez à nouveau en tapant dans votre navigateur http://localhost/monform. Cliquez sur "enregistrer" sans saisir de nom et par magie (ou presque) le formulaire s'affiche à nouveau en précisant les erreurs de validation.
Si par contre, vous saisissez un nom que se passe-t-il? Oui... une exception est levée mais vous devriez comprendre pourquoi. Simple, c'est l'action sauve qui est appelée. Et même si la méthode correspondante existe (et ne fait rien) elle est associée à une vue qui n'existe pas. Vous pouvez la créer en ajoutant le code suivant (sous app/views/scripts/monform/sauve.phtml comme vous le savez maintenant).
Votre nom a été enregistré (ou pas)

20.4.6.Model de données

C'est normalement là que nous nous interessons à l'aspect M (Model) de MVC mais... ce n'est pas pour aujourd'hui.