Une Méthode d'Action est une méthode d'une sous-classe de Zend_Controller_Action identifiée par un nom se terminant par Action. Par exemple : ajouterAction, supprimerAction.

Qu'est-ce qu'une « Action » ? C'est le « service » associé à une ressource. Par exemple, dans la requête suivante :

http://serveur/racineApplication/document/obtenir

la ressource demandée est document et le service sollicité est obtenir. Dans un contexte ZF de base, le contrôleur DocumentController.php (qui sera automatiquement chargé, suivi d'une instanciation) devra contenir la méthode obtenirAction, car c'est cette dernière qui sera appelée par le framework.

L'action par défaut : En abscence de nom de service l'action « indexAction » sera invoquée. Par exemple, dans la requête suivante :

http://serveur/racineApplication/document

la méthode indexAction de l'objet, instance de DocumentController (ou IndexController par défaut), sera appelée.

Il en va de même avec la ressource. En abscence de nom de ressource, c'est la ressource « index » qui sera sollicitée. Par exemple, dans la requête suivante :

http://serveur/racineApplication/

sera interprété comme:

http://serveur/racineApplication/index/index

Cela suppose donc que le contrôleur IndexController et sa méthode indexAction existent !

Sollicitons notre contrôleur ResultatsController :

Figure 6. Interaction avec le contrôleur

Nous avons droit à une erreur, c'est tout à fait NORMAL ! Explications :

En analysant la première ligne (voir encadré) du rapport d'erreur (pas d'affolement, l'analyse de la première ligne suffit dans la majorité des cas), nous constatons que le système recherche le fichier ./application/views/scripts/resulats/index.phtml.

C'est en fait le script responsable de la VUE (le V de MVC), le contrôleur de cas d'utilisation (le C de MVC) ne s'occupant que de la logique de type conversationnel et traitement. Remarque : la partie modèle (le M de MVC) sera introduite dans un autre chapitre.

En effet, il ne devrait pas y avoir d'instruction echo ou print dans un contrôleur (mais parfois des Zend_Debug::dump() ;-).

Comme on a pu le constater, ZF, par défaut, s'attend à ce que le développeur ait conçu des vues pour chaque méthode d'action.

 
     MyApp
     |-- application
     |   |-- controllers
     |   |    |--ResultatsController.php
     |   |               
     |   |-- models 
     |   `-- views 
     |   |    |--scripts
     |   |    |    |--resultats
     |   |    |    |    |--index.phtml
     |-- library 
     |   `-- Zend (racine des librairies de ZF) 
     `-- public
         |-- styles 
         |-- images 
         `-- js 
    
 

Les vues sont stockées dans la branche racine/application/views/scripts/xxx/yyy, ou xxx est le nom de la ressource sollicitée (en référence au contrôleur), et yyy le nom de la vue en relation, de la forme nomDuService.phtml . Le nom du service étant la partie gauche du nom de la méthode d'action. Par exemple :

http://serveur/racineApplication/document/ajouter

la métode ajouterAction de l'objet, instance de DocumentController, sera appelée, puis la vue application/views/scripts/document/ajouter.phtml sera traitée et retournée au client web.

Bien entendu, toute cette logique de traitement est entièrement prise en charge par le framework.

Voici un exemple de vue ./application/views/scripts/resultats/index.phtml :

<h1>Les résultats</h1>

Sollicitons de nouveau notre contrôleur ResultatsController :

Figure 7. Interaction avec le contrôleur : http://.../zfmvc-tuto/resultats/index

Nous avons vu :

Afin de ne pas rentrer ici dans la logique ZF du Modèle, nous nous contenterons d'un Modèle simple représenté par un tableau d'objets Etudiant en mémoire.

Voici donc les classes de notre modèle (voir Intro) :

Figure 10. Classes du modèle

Une représentation objet (Etudiant.php) :

<?php

class Etudiant{
  private $id;
  private $nom;
  private $prenom;

  public function __construct($id, $prenom, $nom){
    $this->nom=$nom;
    $this->prenom=$prenom;
    $this->id=$id;
  }

  public function __toString(){
    return $this->prenom .' '.$this->nom;
  }

  public function setNom($nom) {
    $this->nom=$nom;
  }
  
  public function setPrenom($prenom) {
    $this->prenom=$prenom;
  }

  public function getNom() {
    return $this->nom;
  }
  
  public function getPrenom() {
    return $this->prenom;
  }
}
?>

Enseignant.php :

<?php

class Enseignant{
  private $id;
  private $nom;
  private $prenom;

  public function __construct($id, $prenom, $nom){
    $this->nom=$nom;
    $this->prenom=$prenom;
    $this->id=$id;
  }

  public function __toString(){
    return $this->prenom .' '.$this->nom;
  }

  public function setNom($nom) {
    $this->nom=$nom;
  }
  
  public function setPrenom($prenom) {
    $this->prenom=$prenom;
  }

  public function getNom() {
    return $this->nom;
  }
  
  public function getPrenom() {
    return $this->prenom;
  }
}
?>

Diplome.php :

<?php

class Diplome {
  private $id;
  private $libelle;
  private $nbMinSemainesStage;
  private $idResponsable;

  public function __construct($id,  $idResponsable, $libelle, $minSemStage,){
    $this->id=$id;
    $this->libelle=$libelle;
    $this->nbMinSemainesStage= $minSemStage;  
    $this->idResponsable=$idResponsable;  
  }
  
  
  public function getId() {
    return $this->id;
  }
  
  public function setLibelle($lib) {
    $this->libelle=$lib;
  }

  public function getLibelle() {
    return $this->libelle;
  }
  
  public function setNbMinSemainesStage($n) {
    $this->nbMinSemainesStage=$n;
  }

  public function getNbMinSemainesStage() {
    return $this->nbMinSemainesStage;
  }
  
  public function getNbInscrits(){
    // TODO
    return -1;
  }

}
?>

Et Inscription.php :

<?php

class Inscription{
  private $idEtudiant;
  private $idDiplome;
  private $noteExamen;
  private $nbSemStage;

  public function __construct($idEtudiant, $idDiplome){
    
    $this->idEtudiant=$idEtudiant;
    $this->idDiplome=$idDiplome;
  }

  public function __toString(){
    return $this->idEtudiant .' '.$this->idDiplome;
  }

  public function getIdEtudiant() {
    return $this->idEtudiant;
  }
  
  public function getIdDiplome() {
    return $this->idDiplome;
  }
  
  public function setNoteExamen($note) {
    $this->noteExamen=$note;
  }

  public function getNoteExamen() {
    return $this->noteExamen;
  }

  public function setNbSemStage($n) {
    $this->nbSemStage=$n;
  }

  public function getNbSemStage() {
    return $this->nbSemStage;
  }

  public function estRecu() {
    // TODO
    return false; 
  }

}
?>

L'arborescence s'enrichit :

     MyApp
     |-- application
     |   |-- controllers
     |   |    |--ResultatsController.php
     |   |               
     |   |-- models 
     |   |    |--Etudiant.php
     |   |    |--Enseignant.php
     |   |    |--Diplome.php
     |   |    |--Inscription.php     
     |   `-- views 
     |   |    |--scripts
     |   |    |    |--resultats
     |   |    |    |    |--index.phtml
     |-- library 
     |   `-- Zend (racine des librairies de ZF) 
     `-- public
         |-- styles 
         |-- images 
         `-- js     
 

Pour utiliser des objets de notre modèle, l'application a besoin de connaître leur localisation (application/models). Ceci se réalise dans le bootstrap :

 
<?php
// index.php
error_reporting(E_ALL|E_STRICT);

date_default_timezone_set('Europe/Paris');

set_include_path('.' . PATH_SEPARATOR . './library'
  . PATH_SEPARATOR . './application/models/'
  . PATH_SEPARATOR . get_include_path());

[...]  

  

Nous considérons que la vue dispose d'une collection 'diplomes' (en fait des formations).

 

<style type="text/css">
<!--
table,th,td {
 border-style: solid;
 border-width: 1px;
}

table,caption {
 margin-left: auto;
 margin-right: auto;
 width: auto;
}
-->
</style>
<table>
 <caption>Les diplômes</caption>
 <thead>
  <tr>
   <th>id</th>
   <th>Libellé</th>  
   <th>Nb Inscrits</th>
   <th>Nb Reçus</th>
  </tr>
 </thead>
 <tbody>
 <?php
 foreach ($this->diplomes as $diplome) {
   echo '<tr><td>' . $diplome->getId(). '</td>';
   echo ' <td>' . $diplome->getLibelle() .'</td>';
   echo '<td> &nbsp; </td>';
   echo " <td> &nbsp; </td></tr>\n";
 }
 ?>
 </tbody>
</table>

Ce script de vue exploite un tableau d'objets de type Diplome.

Le contrat qui lie la vue et le contrôleur est simple : La vue considère qu'un contrôleur lui a mis à disposition, sous l'appellation diplomes, une collection d'objets de type Diplome.

Remarque : Dans cette configuration, Contrôleur et Vue sont dépendants du Modèle.

Voici ce que nous obtenons :

Figure 11. http://localhost/.../zfmvc-tuto/resultats

Une erreur attendue ! En effet, le contrôleur n'a pas encore réalisé sa part du contrat. L'erreur vient du fait que la variable $diplomes n'a encore pas d'existence dans le contexte de la vue.

La vue a-t-elle le droit d'y aller franco ?, de ne prendre aucune précaution su l'existence ou non de variables dans son contexte ? la réponse est OUI ! En effet, le cycle de vie des variables de contexte n'est pas de sa responsabilité. Revoir le schéma MVC schéma général.

Le travail sur la vue étant terminé, nous pouvons passer à la logique du contrôleur.

Pour les besoins du test, les données seront provisoirement stockées en mémoire dans un tableau. le contrôleur se chargera de cette tâche, mais ce n'est que PROVISOIRE bien entendu.

Création d'une collection d'objets Diplome :

<?php
class ResultatsController extends Zend_Controller_Action
{
  public function init()
  {
    Zend_Loader::loadClass('Zend_Debug');

  // chargement de la classe Diplome
    Zend_Loader::loadClass('Diplome');

    // creation d'une champ de type collection
    $this->diplomes=array();

    // création des éléments
    for ($i=0; $i<10; $i++) {
      $d = new Diplome($i, 'lib_'.$i, ($i+1)*2);
      $this->diplomes[]=$d;
    }
  }
[...]


 

Nous placerons ces instructions dans le corps de la méthode init de ResultatsController.

La méthode d'action indexAction du contrôleur ResultatsController se charge de pousser les données sur la vue :

  public function indexAction()
  {
    //Zend_Debug::dump("Passe par indexAction de ResultatsController");
    $this->view->diplomes=$this->diplomes;
    $this->render();
  }

Et le tour est joué !

Voici ce que nous obtenons :

Figure 12. http://localhost/.../zfmvc-tuto/resultats

On a vu :

Fichier voirdiplome.phtml

    
<style type="text/css">
<!--
.diplome {
 margin-left: 40px; 
}
-->
</style>
<div class='diplome'>
<h2>Diplôme</h2>
Diplome : <?= $this->diplome->getLibelle() ?> <br>
Nombre de semaines de stage : <?= $this->diplome->getNbMinSemainesStage() ?> <br>
Nombre d'inscrits : <?= $this->diplome->getNbInscrits() ?> <br>
</div>  
  
  

Le problème se pose côté contrôleur : Quel diplome transmettre à la vue ?

Le service devra donc être paramétré. Le contrôleur attend donc une donnée lui permettant de déterminer quel diplome transmettre à la vue. Par défaut le contrôleur transmettre le premier de la liste (index=0).

Voici la méthode d'action en charge de ce cas d'utilisation du contrôleur ResultatsController :

  
     
  public function voirdiplomeAction()
  {
    if ($this->_hasParam('id'))
       $index = $this->_getParam('id');
    else
       $index = 0;

    $this->view->diplome=$this->diplomes[$index];
    $this->render();
  }
  
  

La méthode vérifie qu'elle dispose bien d'un argument ('id'). Si ce n'est pas le cas, elle choisira le premier diplôme (index=0), sinon, elle utilise directement la valeur reçue comme index de collection (très dangereux, à ne pas reproduire !)

Nous obtenons :

Figure 13. http://localhost/.../zfmvc-tuto/resultats/voirdiplome

Noter que la doc API (method _getParam) nous indique que la méthode _getParam admet comme second argument optionnel un valeur par défaut. Ainsi aurions-nous pu écrire :

 $index = $this->_getParam('id', 0);

Nous passerons les arguments par l'URL. Le mode rewrite étant activé sur le serveur HTTP, les arguments peuvent être insrits dans une expression de chemin :

  http:// ... /zfmvc-tuto/resultats/voirdiplome/id/1
  

Équivalent à :

  http:// ... /zfmvc-tuto/resultats/voirdiplome?id=1
  

Sauf que l'expression de chemin est d'un apparence plus stable, donc plus facile à gérer pour les moteurs de recherche, entre autres.

La syntaxe générale de passage d'arguments : .../nom1/val1/nom2/val2/.../nomN/valN

Nous testons le contrôleur en demandant de consulter le deuxième diplôme (id=1)

Figure 14. http://localhost/.../zfmvc-tuto/resultats/voirdiplome/id/1

Enfin, voici les liens logiques liant les éléments de la requête et le contrôleur.

Figure 15. http://localhost/.../zfmvc-tuto/resultats/voirdiplome/id/1

Dans une application de gestion typique (interface avec un SGBDR), il n'est pas rare d'avoir un modèle qui colle aux tables concernées par les responsabilités de l'application.

Dans ce contexte, il parait alors logique de charger le modèle des responsabilités d'accès aux données : create, retreive, update, delete (CRUD).

Pour cela, et pour ne pas avoir à réinventer la roue, il est commode de faire hériter les classes du modèle par une classe prenant en charge les interactions typiques avec un SGBDR. ZF propose la classe Zend_Db_Table_Abstract comme parent de base des classes du modèle.

Voici une description SQL de la structure de la base, fidèle à l'analyse du domaine :

  
  CREATE TABLE  `tutoMvc`.`enseignant` (
  `id` int(11) NOT NULL auto_increment,
  `nom` varchar(50) NOT NULL,
  `prenom` varchar(50) NOT NULL,
  PRIMARY KEY  (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=latin1;

  CREATE TABLE  `tutoMvc`.`diplome` (
  `id` int(11) NOT NULL auto_increment,
  `libelle` varchar(100) NOT NULL,
  `nbMinSemainesStage` int(11) NOT NULL default '0',
  `idResponsable` int(11) NOT NULL,
  PRIMARY KEY  (`id`),
  KEY `resp_diplome_fk_constraint` (`idResponsable`),
  CONSTRAINT `resp_diplome_fk_constraint` FOREIGN KEY (`idResponsable`)
  REFERENCES `enseignant` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=latin1;
  
  CREATE TABLE  `tutoMvc`.`etudiant` (
  `id` int(11) NOT NULL auto_increment,
  `nom` varchar(50) NOT NULL,
  `prenom` varchar(50) NOT NULL,
   PRIMARY KEY  (`id`)
  ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
  
 CREATE TABLE  `tutoMvc`.`inscription` (
  `idEtudiant` int(11) NOT NULL,
  `idDiplome` int(11) NOT NULL,
  `nbSemainesStage` int(11) NOT NULL default '0',
  `note` DECIMAL(2,0) default NULL,
  PRIMARY KEY  (`idEtudiant`,`idDiplome`),
  KEY `res_diplome_fk_constraint` (`idDiplome`),
  CONSTRAINT `res_etudiant_fk_constraint` FOREIGN KEY (`idEtudiant`) 
  REFERENCES `etudiant` (`id`),
  CONSTRAINT `res_diplome_fk_constraint` FOREIGN KEY (`idDiplome`) 
  REFERENCES `diplome` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;  
  

Figure 16. Exemple de définition des tables avec l'outil MySQL Administrator

On remarquera que la table inscription comporte une valeur de champ pouvant ne pas être renseignée.

mysql> describe inscription;
+-----------------+--------------+------+-----+---------+-------+
| Field           | Type         | Null | Key | Default | Extra |
+-----------------+--------------+------+-----+---------+-------+
| idEtudiant      | int(11)      | NO   | PRI |         |       | 
| idDiplome       | int(11)      | NO   | PRI |         |       | 
| nbSemainesStage | int(11)      | NO   |     | 0       |       | 
| note            | decimal(4,2) | YES  |     | NULL    |       | 
+-----------------+--------------+------+-----+---------+-------+

De plus, la base dispose d'un utilisateur non root (login : userWeb, mote de passe : userWeb).

 show grants for userWeb;
+-----------------------------------------------------------------------+
| Grants for userWeb@%                                                  |
+-----------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'userWeb'@'%'                                   |
| IDENTIFIED BY PASSWORD '*5BE427F69545FEA5458A874193160978A8909C15'    | 
| GRANT SELECT, INSERT, UPDATE, DELETE ON `tutoMvc`.* TO 'userWeb'@'%'  | 
+-----------------------------------------------------------------------+

Remarque : cet utilisateur peut être crée via l'entrée "User Administration" de MySQL Administrator.

Voici, pour les tests, quelques instructions d'insertion :

INSERT INTO `tutoMvc`.`enseignant` VALUES  (1,'nomEns1','prenomEns1');
INSERT INTO `tutoMvc`.`enseignant` VALUES  (2,'nomEns2','prenomEns2');

INSERT INTO `tutoMvc`.`diplome` VALUES  (1,'BTS Informatique de Gestion',12,1);
INSERT INTO `tutoMvc`.`diplome` VALUES  (2,'BTS Biotechnologies',14,1);
INSERT INTO `tutoMvc`.`diplome` VALUES  (3,'BTS Design de Produits',4,2);
INSERT INTO `tutoMvc`.`diplome` VALUES  (4,'B2i - Brevet informatique et internet',0,2);

INSERT INTO `tutoMvc`.`etudiant` VALUES  (1,'nomA','prenomA');
INSERT INTO `tutoMvc`.`etudiant` VALUES  (2,'nomB','prenomB');
INSERT INTO `tutoMvc`.`etudiant` VALUES  (3,'nomC','prenomC');
INSERT INTO `tutoMvc`.`etudiant` VALUES  (4,'nomD','prenomD');
INSERT INTO `tutoMvc`.`etudiant` VALUES  (5,'nomE','prenomE');
INSERT INTO `tutoMvc`.`etudiant` VALUES  (6,'nomF','prenomF');
INSERT INTO `tutoMvc`.`etudiant` VALUES  (7,'nomG','prenomG');
INSERT INTO `tutoMvc`.`etudiant` VALUES  (8,'nomH','prenomH');
INSERT INTO `tutoMvc`.`etudiant` VALUES  (9,'nomI','prenomI');
INSERT INTO `tutoMvc`.`etudiant` VALUES  (10,'nomJ','prenomJ');

INSERT INTO `tutoMvc`.`inscription` VALUES  (1,1, 14,13.4);
INSERT INTO `tutoMvc`.`inscription` VALUES  (2,1, 12,9);
INSERT INTO `tutoMvc`.`inscription` VALUES  (3,1, 12, null);
INSERT INTO `tutoMvc`.`inscription` VALUES  (1,4, 18, 0);
INSERT INTO `tutoMvc`.`inscription` VALUES  (2,4, 19, 0);
INSERT INTO `tutoMvc`.`inscription` VALUES  (3,4, 9, 0);

Un backup complet : tutoMvcDataBase.sql .

Nous avons avec la base de données (le SGBDR), deux types de structure à gérer : La table et ses lignes

ZF met à notre disposition deux super-classe Zend_Db_Table_Abstract et Zend_Db_Table_Row_Abstract

Récrivons notre classe modèle Diplome que nous rebaptiserons DiplomeRow (les raisons de ce renommage seront justifiées ultérieurement) :

 
 <?php

// DiplomeRow.php

class DiplomeRow extends Zend_Db_Table_Row_Abstract {
    
  public function getNbInscrits(){
    // TODO
    return -1;
  }

}

  
 

Ainsi que la classe Diplome que nous lions à DiplomeRow :

// Diplome.php
 
class Diplome extends Zend_Db_Table_Abstract {    
  protected $_name = 'diplome';
  protected $_primary = 'id';
  protected $_rowClass = 'DiplomeRow'; 
}


 

C'est tout ? Pour l'instant OUI. Les attributs de la classe DiplomeRow sont auto-générés à partir du nom des attributs de la table (les colonnes).

En relançant http://localhost/.../zfmvc-tuto/resultats/voirdiplome/id/1 , nous obtenons

Fatal error: Class 'Zend_Db_Table_Row_Abstract' 
not found in /.../zfmvc-tuto/application/models/DiplomeRow.php on line 3

Nous devons charger en mémoire les classes Zend_Db_Table_Abstract et Zend_Db_Table_Row_Abstract. Afin d'éviter de répéter l'ordre de chargement dans tous nos modèles, nous placerons dans index.php, le chargement de cette classe :

// chargement de la classe Front du dossier library/Zend/Controller/
Zend_Loader::loadClass('Zend_Controller_Front');
Zend_Loader::loadClass('Zend_Db_Table_Row_Abstract');

[...]
 

Nous obtenons alors, dans le navigateur, une toute autre erreur :

Fatal error: Uncaught exception 'Zend_Db_Table_Exception' with message
 'Argument must be of type Zend_Db_Adapter_Abstract, or a Registry key 
 where a Zend_Db_Adapter_Abstract object is stored'

Et oui ! Nous avons oublié une étape essentielle, celle consistant à spécifier le type de SGBDR et le paramètres de connexion !

Zend Framework met à notre disposition un module de gestion de fichier de configuration Zend_Config_Ini

Nous plaçons alors les données de connexion dans un fichier de configuration à l'abri des regards (./application/config.ini) :

[general]
db.adapter = PDO_MYSQL
db.host = localhost
db.username = userWeb
db.password = userWeb
db.dbname = tutoMvc

Retour donc dans index.php.

Nous définissons un objet Zend_Db_Adapter (voir Manuel en ligne).

[...]
include "Zend/Loader.php";
Zend_Loader::loadClass('Zend_Controller_Front');

Zend_Loader::loadClass('Zend_Db');
Zend_Loader::loadClass('Zend_Db_Table_Abstract');


// Chargement automatique de Zend_Db_Adapter_Pdo_Mysql, et instanciation.
$config = new Zend_Config_Ini('./application/config.ini', 'general');

$db = Zend_Db::factory($config->db->adapter,array(
   'host'  => $config->db->host, 
  'username'  => $config->db->username,
  'password'  => $config->db->password,
  'dbname'  => $config->db->dbname,
    )
);

// placons la connexion dans un registre global à l'application
Zend_Loader::loadClass('Zend_Registry');
$registry = Zend_Registry::getInstance();
$registry->set('db', $db);


[...]

On remarquera la souplesse d'utilisation de Zend_Config_Ini : les clés du fichier de configuration sont traduites en propriétés public, ce qui nous permet de consulter une valeur associée à une clé par : instance_Zend_Confi_Ini->clé

Nous devons repenser le contrôleur et la vue. En effet, comme nous le verrons, nous n'avons plus à faire à des objets dans un tableau créés par le contrôleur, mais à une collection "RowSet" (ens. de lignes) d'objets de type "Row" (ligne).

Les objets de type Zend_Db_Table_Row, sont automatiquement spécialisés par ZF en fonction du modèle.

Il est temps maintenant de modifier notre contrôleur :

class ResultatsController extends Zend_Controller_Action
{

  public function init()
  {
    Zend_Loader::loadClass('Zend_Debug');

    // chargement de la classe Diplome 
    Zend_Loader::loadClass('Diplome');    
  }

  public function indexAction()
  {
    // on retrouve le registre global  
    $registry = Zend_Registry::getInstance();
    // et notre connexion
    $db = $registry->get('db');
    
    // que l'on passe au constructeur (hérité) de notre modèle
    $d = new Diplome($db);
    
    // obtenons un objet Zend_Db_Select (capable d'appliquer des restrictions)
    $select = $d->select();
    
    // aucune clause where
    
    // nous transmettons à la vue l'ensemble des lignes de la table diplome
    // soit un objet Zend_Db_Table_Rowset 
    //    (colection d'objets DiplomeRow - des Zend_Db_Table_Row) 
    $this->view->diplomes=$d->fetchAll($select);    

    $this->render();
  }
[...]

Connexion par défaut

Si l'application n'accède qu'à une seule base de données, on peut, par exemple dans le bootstrap (index.php), spécifier une connexion par défaut. Zend_Db_Table::setDefaultAdapter($db); Zend_Registry::set('dbAdapter', $db); Ainsi, dans le contrôleur, le code se trouve encore réduit : : // SANS connexion par défaut // on retrouve le registre global $registry = Zend_Registry::getInstance(); // et notre connexion $db = $registry->get('db'); // que l'on passe au constructeur (hérité) de notre modèle $d = new Diplome($db); //AVEC connexion par défaut (une seule instruction !) // Aucun argument à la construction. // Liaison automatique via la connexion par défaut $d = new Diplome();

Le script de vue views/resultats/index.phtml doit légèrement être impacté.

En effet, les attributs automatiques de notre modèle sont directement accessibles (non privés). Donc l'instruction $diplome->getId() sera transformée en $diplome->id, tout simplement. Voici les changements à apporter :

 
<?php
 foreach ($this->diplomes as $diplome) {
   echo '<tr><td>' . $diplome->id  . '</td>';
   echo ' <td>' . $diplome->libelle .'</td>';
   echo ' <td>' . $diplome->idResponsable .'</td>';
   echo '<td> &nbsp; </td>';
   echo " <td> &nbsp; </td></tr>\n";
 }

Figure 17. resultats/index.phtml

Les opérations de base SQL sur les données (interrogation, création, modification, suppression) sont assistées par des méthodes héritées de Zend_Db_Table_Abstract. En effet, ces responsabilités sont conceptuellement soit de niveau 'table', soit de niveau 'objet métier' ('tuple'). En voici quelques exemples :

// Fontion de niveau 'table' 
 $dt = new Diplome();  
 $diplome = $dt->find(1)->current();  
 

// Fontion de niveau 'tuple' 
 $dt = new Diplome();  
 $diplome = $dt->find(1)->current();
 $diplome->libelle = "new libelle";
 $diplome->save();
 

// Fontion de niveau 'tuple' 
 $dt = new Diplome();  
 $diplome = $dt->find(4)->current();
 $diplome.delete();
 

// Fontion de niveau 'table' et 'tuple'
  $dt = new Diplome(); 
  // les données sont représentées par un dictionnaire
  $data = array(  
    'libelle' => 'BTS IRIS',
    'nbMinSemainesStage' => 10,
    'idResponsable' => 1
  ); 
  $diplome=$dt->createRow($data);  
  if ($diplome ) {
    $id=$diplome->save();
    $this->view->diplome=$diplome;
  }    
 

 $db = Zend_Registry::get('dbAdapter');
 $db->beginTransaction();
 try {
    // insert etudiant
    [...]    
    
    // insert diplome avec une clé primaire erronée 
    $data = array(
     'id' => 1,  
     'libelle' => 'BTS IRIS',
     'nbMinSemainesStage' => 10,
     'idResponsable' => 2
    );   
    $d = new Diplome();
    $d->insert($data);
    
    // demande d'exécution du lot des opérations    
    $db->commit();    
    $this->render();
 } catch (Exception $e) {
    // annule toutes les opérations du lot
    $db->rollBack();
    $this->_redirect('/');
 }

En référence à notre schéma relationnel ('voir la définition des tables), nous intervenons dans la définition des classes de type 'Table'

 
 <?php

class Diplome extends Zend_Db_Table_Abstract {
    
  protected $_name = 'diplome';
  protected $_primary = 'id';
  protected $_rowClass = 'DiplomeRow';
      
  protected $_referenceMap    = array(
        'Responsable' => array(
            'columns'           => 'idResponsable',
            'refTableClass'     => 'Enseignant',
            'refColumns'        => 'id'
        ));
}
?>
 
 <?php
class Inscription extends Zend_Db_Table_Abstract {

  protected $_name = 'inscription';
  protected $_rowClass = 'InscriptionRow';

  protected $_referenceMap    = array(
        'Diplome' => array(
            'columns'           => array('idDiplome'),
            'refTableClass'     => 'Diplome',
            'refColumns'        => array('id')
  ),
        'Etudiant' => array(
            'columns'           => array('idEtudiant'),
            'refTableClass'     => 'Etudiant',
            'refColumns'        => array('id')
  )
  );
}
?> 
 

$_referenceMap est une propriété héritée, qui permet de définir le rôle de chacune des clés étrangères de la table concernée. Chaque rôle est identifié par un :

Une cas typique consiste à exploiter le tuple associé à une clé étrangère. Par exemple, dans le tableau qui liste les diplômes, nous souhaiterions voir apparaître, non pas l'identifiant du responsable, mais son nom.

Actuellement le code de la vue est :

 
<?php
 foreach ($this->diplomes as $diplome) {
   echo '<tr><td>' . $diplome->id . '</td>';
   echo ' <td>' . $diplome->libelle .'</td>';
   echo ' <td>' . $diplome->idResponsable .'</td>';
   echo '<td> &nbsp; </td>';
   echo " <td> &nbsp; </td></tr>\n";
 }

Fidèle à nos principes (architecture MVC, patterns GRASP), ce n'est pas de la responsabilité de la vue de contenir le code d'extraction du nom du responsable dans le modèle : C'est le diplome qui connaît son responsable, nous nous adresserons donc à ce dernier.

<?php
 foreach ($this->diplomes as $diplome) {
   echo '<tr><td>' . $diplome->id . '</td>';
   echo ' <td>' . $diplome->libelle .'</td>';
   echo ' <td>' . $diplome->getResponsable()->nom .'</td>';
   echo '<td> &nbsp; </td>';
   echo " <td> &nbsp; </td></tr>\n";
   echo " <td> <a href='voiretudiants/diplome/$diplome->id'>voir</a> </td></tr>\n";
 }

Nous intervenons donc au niveau de la classe des objets de type Row, afin de "déréférencer" une clé étrangère.

Pour cela nous utiliserons la méthode findParentRow héritée de la classe Zend_Db_Table_Row_Abstract :

Figure 18. findParentRow

  
  <?php
class DiplomeRow extends Zend_Db_Table_Row_Abstract {
  
  public function getResponsable() {
    return $this->findParentRow('Enseignant');
  }
  
  public function getNbInscrits(){
    // TODO
    return -1;
  }
}
?>    
  

La méthode findParentRow exploite les données de $_referenceMap pour sélectionner la ligne (Row) de la table enseignant liée à l'instance courante (relative à une ligne de la table diplome).

La méthode findParentRow attend deux arguments : Le premier est le nom d'une 'TableClass' et le deuxième (optionnel) est une clé de $_referenceMap, soit le nom du rôle de la relation.

Nous pouvons alors tester le résultat :

Figure 19. resultats/index.phtml

Nous venons de voir comment utiliser Zend Framework pour réaliser une jointure retournant au plus une ligne.

Nous nous intéressons maintenant à la relation Un-à-Plusieurs (One To Many) .

Je souhaite connaître l'ensensemble des étudiants inscrits à un diplome (à une formation diplomante).

Plusieurs alternatives s'offrent à nous :

Dans le respect du pattern Expert en Information, nous choisirons la deuxième solution.

Comme vous l'avez certainement constaté , le lien nommé 'voir' : <a href='voiretudiants/diplome/$diplome->id'>voir</a> fait référence à une méthode d'action du contrôleur courant, que nous devons concevoir. Mais intéressons-nous en premier à sa vue :

<style type="text/css">
<!--
table,th,td {
 border-style: solid;
 border-width: 1px;
}

table,caption {
 margin-left: auto;
 margin-right: auto;
 width: auto;
}
-->
</style>
<table>
 <caption>Les étudiants inscrits au diplôme <?=$this->diplome ?></caption>
 <thead>
  <tr>
   <th>Etudiant</th>
   <th>Stage <br>Nombre de <br>semaines réalisé</th>  
   <th>note</th>
   <th>reçu</th>
  </tr>
 </thead>
 <tbody>
 <?php
 foreach ($this->inscriptions as $inscription) {
   echo '<tr><td>' . $inscription->getNomEtudiant() . '</td>';
   echo ' <td>' . $inscription->nbSemainesStage .'</td>';
   echo '<td>'. $inscription->note .'&nbsp; </td>';
   echo '<td>'.$inscription->estRecu() ."&nbsp;</td></tr>\n";
 }
 ?>
 </tbody>
</table>

 
 //ResultatsController.php
  public function voiretudiantsAction()
    {
      $idDplome=$this->_getParam('diplome', 1);

      $dt = new Diplome();
      $diplome = $dt->find($idDplome)->current();
      $inscriptions=$diplome->getInscriptions();
      $this->view->inscriptions=$inscriptions;
      $this->view->diplome=$diplome->libelle;
      $this->render();
    }   

19.3.3. Méthode de liaison entre modèle

Sur cette base nous pouvons implémenter la méthode getInscriptions de la classe DiplomeRow.

Pour cela nous utiliserons la méthode findDependanteRowset héritée de la classe Zend_Db_Table_Row_Abstract :

Figure 20. findDependanteRowset

Soit :

  
<?php

class DiplomeRow extends Zend_Db_Table_Row_Abstract {

  public function getInscriptions(){
    return  $this->findDependentRowset('Inscription');
  }
  
  public function getResponsable() {
    return $this->findParentRow('Enseignant');
  }
  
  public function getNbInscrits(){
    // TODO
    return -1;
  }

}
?> 

La méthode findDependentRowset retourne un Rowset (et non pas un Row comme précédemment, qui est l'ensemble des objets InscriptionRow (relatifs aux lignes) lignes de la table inscription qui sont en relation avec this.

	Le rôle des relations
	La méthode findDependentRowsetpeut prendre un deuxième argument, dont la valeur est un des noms de rôle (clé de $_referenceMap de la classe en premier argument) return $this->findDependentRowset('Inscription', 'Diplome');

Avec la logique One-To-One (à une ligne de la table inscription correspond un étudiant, un diplome), nous pouvons coder la classe InscriptionRow :

  
  <?php

class InscriptionRow extends Zend_Db_Table_Row_Abstract {
   
  //  private $idEtudiant;
  //  private $idDiplome;
  //  private $noteExamen;
  //  private $nbSemStage;

  public function estRecu() {
    // TODO
    return false;
  }

  public function getNomEtudiant() {
    return $this->findParentRow('Etudiant')->nom;
  }

  public function getLibDiplome() {
    return $this->findParentRow('Diplome')->libelle;
  }

}
?>  

19.3.4. Résultats

Index des diplômes, avec lien vers les étudiants inscrits

Figure 21. views/sccripts/resultats/index.phtml

Figure 22. Etudiants inscrits à un diplôme

Cas d'une table relation non porteuse de propriétés

Une table relation, connue également sous l'appellation table intersection, est une table dont la seule raison d'être est de mettre en relation deux tuples (d'une même table ou de tables différentes). Lorsque ces tables ne portent pas d'autres informations (cas d'une association N-N non porteuse de propriété dans le schéma conceptuel), à l'utilisation, leurs clés étrangères sont très souvent systématiquement "déréférencées".

Zend Framework fournit une façon directe d'exploiter des association non porteuse.

Figure 23. Many To Many

Prenons un exemple, (bien que nous n'ayons pas de table relation on porteuse, mais qui peut le plus peu le moins), si nous avions voulu simplement prendre connaissance des identités des étudiants inscrits à un diplôme, sans en connaître les détails (note, durée effective des stages...). C'est à dire que nous souhaitons obtenir la listes des étudiants inscrits (objet EtudiantRow) et non la liste des inscrits (objet InscriptionRow) :

// DiplomeRow.php

  // obtenir tous les étudiants inscrits à ce diplome
  public function getEtudiants() {
    return $this->findManyToManyRowset('Etudiant', 'Inscription');
  }
  

La méthode findManyToManyRowset prend en argument le nom de (ou un objet de) la classe correspondant au Rowset à retourner (ici se sera des objets Etudiant) et en deuxième argument, ce que la documentation zend.db.table.relationships.html nomme table intersection (connu aussi sous l'appelation 'table de relation'). La méthode reçoit optionnellement d'autres arguments comme le rôle dans $_referenceMap (sinon c'est le premier rôle qui est élu).

Si vous avez respecté les conventions de nommage utilisées dans ce support, pour pouvez alors utiliser les fonctions "magiques" de navigation dans le modèle.

Une méthode magique est une méthodes non déclarée par le développeur, mais respectant des conventions de nommage de sorte que Zend_Db_Table_Row_Abstract puisse en déduire les bons appels. Par exemple

// DiplomeRow.php
...
public function getInscriptions(){
    return  $this->findInscription();
}
...   

sera interprété : $this->findDependentRowset('Inscription')

Il en va de même avec EtudiantViaInscription

// DiplomeRow.php
...

public function getEtudiants() {
   return $this->findEtudiantViaInscription();
   //return $this->findManyToManyRowset('Etudiant', 'Inscription');
}
...    

Plus d'information avec le guide du développeur et l'API

Un filtre est une fonction de transformation d'une donnée d'entrée, soumise par un client, en une donnée conforme pour le système : simplification, ajout de code d'échappement...

Il existe de nombreux filtres prêts à l'emploi. Un filtre est un objet, instance d'une classe qui implémente Zend_Filter_Interface.

Par exemple :

    $prenom = new Zend_Form_Element_Text('prenom');
    $prenom->setLabel('Prénom');
    $prenom->setRequired(true);
            
    $filter = new Zend_Filter_StripTags();
    $prenom->addFilter($filter);                
 

Le filtre StripTags supprimera toute balise présente dans prénom (afin de se prémunir d'injection de code HTML).

Les filtres peuvent être chaînés :

    ...       
    $filter = new Zend_Filter_StripTags();
    $nom->addFilter($filter);          
    $nom->addFilter(new Zend_Filter_StringToUpper());
    ...      
 

Dans ce cas, les filtres sont appliqués par ordre d'insertion dans le composant. Ici, les balises seront supprimées avant la passage en majuscule.

Plus loin avec les filtres : Zend_Filter.

Un validateur est une fonction booléenne qui reçoit une donnée d'entrée, et retourne vrai si son argument est conforme aux règles de gestion prises en charge par le validateur, retourne faux sinon.

De plus, le validateur peut fournir des informations sur les règles non respectées, comme une chaîne vide, ou trop courte ou ne respectant pas une certaine syntaxe, etc.

Il existe de nombreux validateurs prêts à l'emploi. Un validateur est un objet, instance d'une classe qui implémente Zend_Validate_Interface.

Par exemple :

    $prenom = new Zend_Form_Element_Text('prenom');
    $prenom->setLabel('Prénom');
    $prenom->setRequired(true);
    $prenom->addValidator(new Zend_Validate_NotEmpty());                
 

Les validateurs peuvent être chainés :

    ...       
    $nom->addValidator(new Zend_Validate_StringLength(2));          
    $nom->addValidator(new Zend_Validate_Alnum());
    // ou $nom->addValidator('Alnum'); // le framework se chargeant de la correspondance
    ...      
 

Dans ce cas, les validations sont appliqués par ordre d'insertion dans le composant. Ici, le test de la longueur minimale est réalisé en premier, puis, quelqu'en soit le résultat le seconde test sera lui aussi évalué (caractères alphanumériques uniquement).

Exemple de validateurs standards : EmailAddress, Date, Barcode, Between, Float, Hex, Regex... Voir ici : Zend_Validate

 
 function addetudiantAction()
  {       
        $this->view->title = "Ajouter un étudiant";
        $form = new EtudiantForm();
        
        // reception de donnees ?       
        if ($this->_request->isPost()) {
            $formData = $this->_request->getPost();
//          Zend_Debug::dump($formData);

            // nous les affectons au formulaire 
            $form->populate($formData);
            
            // qui applique les filtres
            $formData=$form->getValues();
            
            //Zend_Debug::dump($formData);
            // activation des validateurs
            if ($form->isValid($formData)) {
                // ok, nous pouvons opérer              
                $et=new Etudiant();
                $etudiant=$et->createRow($formData);  
                if ($etudiant ) {
                  // sauvegarde dans la BD
                  $id=$etudiant->save();
                  // transmission des données à la vue 'voiretudiant.phtml'
                  $this->view->etudiant=$etudiant;                  
                  $this->render('voiretudiant');
                  return;           
                } 
            }
        }                
        // présentation du formulaire
        $this->view->form = $form;
        $this->render();
  }
  
 
 

Comme on peut le constater, en cas de non validation ou de requête non POST, le formulaire est retourné au client. Ci-dessous un exemple de retour avec informations transmises par les différents validateurs.

Figure 25. http://localhost/~kpu/wsPhp/zfmvc-tuto/index/addetudiant

Rien de nouveau pour cette vue associée voiretudiant.phtml :

 
<style type="text/css">
<!--
table,th,td {
 border-style: solid;
 border-width: 1px;
}

table,caption {
 margin-left: auto;
 margin-right: auto;
 width: auto;
}
-->
</style>
<table>
 <caption>Etudiant </caption>
 <thead>
  <tr>
   <th>Id</th>
   <th>Nom</th>  
   <th>Prénom</th>
  </tr>
 </thead>
 <tbody>
 <?php
   echo '<tr><td>' . $this->etudiant->id. '</td>';
   echo '<td>'. $this->etudiant->nom .'&nbsp; </td>';
   echo '<td>'.$this->etudiant->prenom ."&nbsp;</td></tr>\n";
 ?>
 </tbody>
</table>
 
 

Exemple d'un ajout réussi :

Figure 26. http://localhost/~kpu/wsPhp/zfmvc-tuto/index/addetudiant

Zend Framework est livré, entre autres, avec les modules permettant le gestion des authentifications (Zend_Auth) et des droits (Zend_Acl).

Vous trouverez ici un tutoriel Rob Allen sur la question, traduit en français.

Le module Zend_Session propose une alternative à l'utilisation brute du tableau $_SESSION. En effet, Zend_Session intègre la notion d'"espace de noms" dans la zone de stockage des données de session, limitant ainsi des conflits de noms. Voir Guide du programmeur : Zend_Session

Le module Zend_Layout permet d'encapsuler le contenu d'une vue dans une autre, bien que pouvant être utilisé sans MVC, le module est conçu pour s'intégrer avec ce dernier, utilise Zend_View. Voir Guide du programmeur : Zend_Layout