17 février 2010
Résumé
Support de cours à destination d'étudiants en formation professionnelle (BAC +2), BTS Informatique de Gestion option Développeur d'Applications.
Prérequis :
Concepts de base de l'objet, première expérience dans un langage (Java)
HTML et SQL dans les grandes lignes
Objectifs :
Découvrir par la pratique le potentiel structurant d'une architecture MVC et de la programmation objet (PHP >=5)
Approche progressive : Vue et Contrôleur et Modèle avec données sont abordés en premier, puis la navigation dans le Modèle et Formulaire
A la fin de cet apprentissage, l'étudiant détient des clés pour :
Approfondir l'utilisation des objects techniques présentés.
Exploiter la documentation officielle du framework : API et Manuel
Étendre sa recherche vers d'autres modules du framework (Zend_Auth , Zend_Acl, Zend_Layout, Zend_Pdf, Zend_Cache, ...)
Document au format docbook , mis en page avec le processeur xsltproc et les feuilles de styles de Norman Walsh.
Ce document est placé sous la Licence GNU Free Documentation License, Version 1.1 ou ultérieure publiée par la Free Software Foundation.
Table des matières
Un version PDF ici (une contribution de Boris Vacher) : tabPooPhpJava.pdf
D'un point de vue "physique", les architectures d'applications sont traditionnellement réparties en trois catégories :
Autonome
C'est le cas d'applications qui ne dépendent pas de systèmes tiers, autres que ceux généralement offerts par un système d'exploitation.
Client/Serveur
Modèle phare des années 80, où le système d'information est centré sur les données. La logique métier est répartie, plus ou moins, entre le client (qui détient/exécute les formulaires) et le serveur (SGBDR).
Architecture 3 tiers (et plus)
Tiers veut dire parties. Alors que les applications C/S sont de types 2 parties (le client IHM et le SGBDR), les architectures n tiers (pour n > 2) font intervenir un middleware applicatif responsable de la logique applicative. Le terme middleware est à prendre dans le sens intermédiaire de communication entre 2 niveaux.
Cette vue par "parties" (tiers) correspond à « un changement de niveau dès qu'un module logiciel doit passer par un intermédiaire de communication (middleware) pour en invoquer un autre » - ref : www.octo.com.
Le modèle n tiers le plus répandu des années 2000 est le modèle 3 tiers Web, typiquement représenté par :
Navigateur <----> Serveur d'applications <-----------> SGBDR présentation http pages dynamiques middleware coordination composants logiciels SGBD
C'est ce modèle que nous vous proposons d'exploiter, en environnement Php.
Le succès de PHP vient de sa faciliter à combiner, dans un même document, à la fois du HTML, CSS, instructions PHP et requêtes SQL. Si le développeur ne met pas un peu d'ordre il en résulte un vrai bazar fragile, difficilement extensible, peu modulable et très difficile à maintenir.
Oui, mais comment mettre de l'ordre ?
une réponse courante à ce problème consiste à séparer physiquement les différentes logiques. Typiquement on distingue :
La logique de présentation : partie de l'application en interaction avec l'utilisateur
La logique de traitement : partie de l'application qui réagit aux événements
La logique de persistance : concerne la logique de stockage des données (via un SGBDR par exemple)
il est alors facile d'identifier ces parties avec les langages mis en oeuvre dans des applications Web... sauf que là aussi, plusieurs modèles sont possibles.
Client léger (ou pauvre) : la partie IHM est en (X)HTML + CSS
Client riche : utilise un maximum de ressources du client Web (JavaScript, Ajax...) avec un minimum de problématique de déploiement (respect des standards du W3C). Exemples : Netvibes, GMail.
Nous nous concentrerons sur le client léger.
Remarque : le modèle client lourd concerne le client qui exécute de la logique de traitement en s'appuyant sur des composants dédiés et déployés pour l'occasion (le navigateur ne suffit pas). Exemple application Swing.
Le moèdel MVC (Model View Controller) adapté au Web est une réponse à une division des responsabilités.
Dans ce contexte :
la partie Vue est prise en charge par un script (PHP ou autre langage) générant du HTML (sans autre logique de traitement)
la partie contrôleur est représentée par un script PHP qui déclenche des traitements liés aux services (Use Case) auquel il est attaché (Un contrôleur par Use Case)
la partie Modèle est représentée par des scripts PHP gérant les accès au SGBDR. Cela peut être par exemple des classes Métier qui implémentent des fonctions CRUD vers un SGBDR.
Remarquez que les framework applicatifs (CMS, Forum, ...) sont généralement basés sur une architecture MVC. D'autres exemples ici : http://fr.wikipedia.org/wiki/Liste_de_frameworks_PHP
Pourquoi utiliser un framework ?
En informatique, un framework peut être vu comme un outil de travail adaptable. C'est un ensemble de bibliothèques, d'outils et de conventions permettant le développement rapide d'applications. Un framework est composé de briques logicielles organisées pour être utilisées en interaction les unes avec les autres. L'utilisation d'un framework permet le partage d'un savoir-faire technologique et impose suffisamment de rigueur pour pouvoir produire une application aboutie et facile à maintenir ( voir Framework sur Wikipedia).
Nous utiliserons Zend Framework. ZF est un framework Open Source de la société Zend qui se veut modulaire et modulable.
Tableau 1. Voici quelques modules du Zend Framework
Core: Zend_Controller Zend_View Zend_Db Zend_Config Zend_Filter Zend_Valdiate Zend_Registry | Authentication and Access: Zend_Acl Zend_Auth Zend_SessionZend_Controller |
Internationalization: Zend_Date Zend_Locale Zend_Measure |
Http: Zend_Http_Client Zend_Http_Server Zend_UriZend_Controller | Inter-application communication: Zend_Json Zend_XmlRpc Zend_Soap Zend_Rest |
Web Services: Zend_Feed Zend_Gdata Zend_Service_Amazon Zend_Service_Flickr Zend_Service_Yahoo |
Advanced: Zend_Cache Zend_Search Zend_Pdf Zend_Mail/Zend_Mime |
Misc! Zend_Measure |
|
Une solution (L|M|W)AMP est requise. La version de PHP >= 5.2.4 Le mode rewrite d'apache doit être activé. Plus d'info ici.
La dernière version du framework http://framework.zend.com/download/
Ainsi que la documentation API : http://framework.zend.com/apidoc/core/ et Guide du programmeur : http://framework.zend.com/manual/fr/
Voir ce site dédié au framework PHP en français : http://www.z-f.fr/
L'objectif est d'isoler physiquement les différentes logiques (vues, contrôleurs, modèles, zone publique, librairies)
Pour ce faire, il est nécessaire d'établir une arborescence de répertoires. Nous utiliserons celle-ci :
NomDuProjet |-- application | |-- configs | |-- controllers | |-- forms | |-- layouts | |-- models | `-- views |-- library | `-- Zend (racine - ou lien vers - des librairies de ZF) `-- public | |-- css `-- scripts |-- (des scripts sql par exemple)
La zone publique contiendra des ressources directement accessibles. Par exemple via l'url http://localhost/~kpu/ZFQuickstart/public/myImage.png
.
On veillera à interdire l'accès aux autres répertoires.
On entend par modèle la couche ayant en charge les données. Cette couche de service interagit avec le système de persistance, les contrôleurs et les vues.
Un contrôleur est le point d'entrée d'un cas d'utilisation.
Les responsabilités d'un contrôleur de cas d'utilisation sont :
Prendre en charge la logique du service demandé (les traitements)
Interagir pour cela avec les données de l'application, représentées par le modèle (le M de MVC)
Transmettre à la vue les informations dont elle a besoin pour une réponse personnalisée en direction du demandeur (client web)
Les responsabilités d'une vue sont :
Présenter les informations dont elle dispose (voir contrôleur).
Gérer la présentation de l'absence possible de certaines informations (liste vide par exemple)
Contrôleurs et Vues sont donc liés par un contrat :
La vue prend en charge la présentation des informations
Le contrôleur, après traitement, est tenu de transmettre à la vue les informations dont elle a la charge
Comme on le verra bientôt, les contrôleurs sont implémentés sous forme d'objet (classe spécialisée) et leurs actions sous forme de méthodes d'instance, dites méthode d'action.
Les informations peuvent provenir d'une base de données, et/ou de données calculées, préparées par la méthode d'action. Le schéma général est :
On trouvera d'autres représentations ici.
L'étape suivante vise à installer ces notions, indépendamment du contexte du quickstart, l'idée étant de nous « accrocher » à une base de données, avec une technique d'impléméntation du modèle plus rudimentaire que celle proposée par l'application quickstart (qui fait référence au modèle de conception Data Mapper de Martin Fowler ).
Certains détails de la procédure décrite ici concerne essentiellement ceux qui ont un compte sur un serveur
unix ou GNU/Linux, en non root, avec le mode userdir
d'apache activé avec les paramètres par défaut - bref ceux
qui ont leur racine de publication nommée public_html
dans leur home directory.
Nous proposons dans ce tutoriel une approche progressive des concepts et techniques mis en oeuvre par le framework, à destination des débutants.
en ligne de commande
# dans le dossier bin de ZF ZendFramework-1.9.5/bin$ ./zf.sh create project zf-tuto # on deplace le projet à la racine de publication mv zf-tuto/ ~/public_html # aller dans le dossier cd ~/public_html/zf-tuto # déplacer dans les fichiers de démarrage à la racine mv public/index.php . mv public/.htaccess . # modifier les chemins dans index.php // Define path to application directory defined('APPLICATION_PATH') || define('APPLICATION_PATH', realpath(dirname(__FILE__) . '/application')); # ajouter le chemin des modeles // Ensure library/ is on include_path set_include_path(implode(PATH_SEPARATOR, array( realpath(APPLICATION_PATH . '/../library'), realpath(APPLICATION_PATH . '/models'), get_include_path(), ))); # modifier .htaccess RewriteBase /~XXX/zf-tuto # dans library/ créer un lien symbolique vers ou copier y le dossier ZendFramework-1.9.5/libray/Zend
Voila, l'installation du squelette du projet est terminée. Vous remarquerez que le fichier index.php ne comporte aucune logique de l'application ; en effet son rôle est principalement technique. Le terme technique est, dans ce contexte, opposé au terme métier, ce dernier terme faisant référence à la logique de l'application régie par les règles de gestion liées au problème à résoudre.
Faire un test : http://localhost/~XXX/zf-tuto
Parallèlement à la création du projet, nous installons la base de données « world » sur un serveur MySQL.
« world » est une base de données statistiques géo-politiques sur le monde datant de 2006, d'après Official Statistics of Finland.
La base de données que nous installons est issues de MySql : world - légèrement modifiée pour l'occasion (vous trouverez ici les grandes lignes de la modifcation) .
Instructions rapides : télécharger le script world2.zip et le décompresser.
mysql -u root < world2-schema.sql mysql -u root < world2-data.sql
Voici une description SQL de la structure de la table « Country » (on aurait pu en choisir une autre)
mysql> describe Country; +----------------+--------------------------------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +----------------+--------------------------------------+------+-----+---------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | Code | char(3) | YES | | NULL | | | Name | char(52) | NO | | | | | Continent | enum('Asia','Europe', | | | | | | | 'North America', 'Africa','Oceania', | | | | | | | 'Antarctica','South America') | NO | | Asia | | | Region | char(26) | NO | | | | | SurfaceArea | float(10,2) | NO | | 0.00 | | | IndepYear | smallint(6) | YES | | NULL | | | Population | int(11) | NO | | 0 | | | LifeExpectancy | float(3,1) | YES | | NULL | | | GNP | float(10,2) | YES | | NULL | | | GNPOld | float(10,2) | YES | | NULL | | | LocalName | char(45) | NO | | | | | GovernmentForm | char(45) | NO | | | | | HeadOfState | char(60) | YES | | NULL | | | Capital | int(11) | YES | | NULL | | | Code2 | char(2) | NO | | | | +----------------+--------------------------------------+------+-----+---------+----------------+
Par simple commodité ici, nous utiliserons l'utilisateur 'root' alors que nous devrions créer d'un utilisateur ou plusieurs utilisateurs spécifiques pour cette base (par exemple via l'entrée "User Administration" de MySQL Administrator.
Combien de lignes contient cette table ?
$ mysql -u root world2 mysql> select count(*) as `nombre de pays` from Country; +----------------+ | nombre de pays | +----------------+ | 239 | +----------------+
Il est temps maintenant de configurer la connexion à la base de données.
Nous ajoutons quelques lignes à application/configs/application.ini
(ZF utilise PDO pour l'accès aux données)
[production] ... database.adapter = PDO_MYSQL database.params.host = localhost database.params.username = root database.params.password = database.params.dbname = world2
Puis nous exploitons ces informations au démarrage (dans index.php)
-- dans index.php
// Chargement automatique de Zend_Db_Adapter_Pdo_Mysql, et instanciation.
$config = new Zend_Config_Ini('./application/configs/application.ini', 'production');
$db = Zend_Db::factory($config->database->adapter,array(
'host' => $config->database->params->host,
'username' => $config->database->params->username,
'password' => $config->database->params->password,
'dbname' => $config->database->params->dbname,
)
);
// placons la connexion dans un registre global à l'application
$registry = Zend_Registry::getInstance();
$registry->set('db', $db);
// en faire la connexion par defaut
Zend_Db_Table::setDefaultAdapter($db);
Nous définissons un objet Zend_Db_Adapter
(voir Manuel en ligne).
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 allons voir maintenant comment lier une classe à cette table.
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).
Il est commode alors 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.
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-classes Zend_Db_Table_Abstract
et Zend_Db_Table_Row_Abstract
Concevons une classe modèle représentant une instance d'un pays : CountryRow
(les raisons de ce nommage seront justifiées ultérieurement) :
Remarque : les classes du modèle seront placées dans le dossier « models »
ZFQuickstart
|-- application
| |-- controllers
| |-- models
| | |--CountryRow.php
| `-- views
|-- library
| `-- Zend (racine des librairies de ZF)
`-- public
|-- styles
|-- images
`-- js
<?php // CountryRow.php class CountryRow extends Zend_Db_Table_Row_Abstract { public function getNbCities(){ // TODO return -1; } }
Nous concevons en plus la classe Country
que nous lions à CountryRow
:
// Country.php
class Country extends Zend_Db_Table_Abstract {
protected $_name = 'Country';
protected $_primary = 'id';
protected $_rowClass = 'CountryRow';
}
C'est tout ? Pour l'instant OUI. Les attributs de la classe CountryRow
sont auto-générés à partir du nom des attributs de la table (les colonnes).
C'est ainsi que vous pouvez redéfinir l'ensemble des classes du modèle.
Nous allons concevoir la Consultation de l'ensemble des pays.
C'est un cas d'utilisation du sytème. Nous allons donc mettre en place un contrôleur de cas d'utilisation.
Ce contrôleur sera accessible par l'url : http://localhost/~kpu/zf-tuto/country
Par défaut, ZF fait correspondre à cette ressource un script PHP bien particulier.
Hormis le fait que le nom de ce script est basé sur le nom de la ressource (ici Country
)
suivi du mot Controller
(on remarquera la capitalisation des termes), ce script, qui est en fait une classe
héritant de Zend_Controller_Action, sera placé dans la branche controllers
:
ZFQuickstart
|-- application
| |-- controllers
| | |--CountryController.php
| |
| |-- models
| `-- views
|-- library
| `-- Zend (racine des librairies de ZF)
`-- public
|-- styles
|-- images
`-- js
Voici le contrôleur en question :
<?php class CountryController extends Zend_Controller_Action { public function init() { } public function preDispatch() { } public function indexAction() { $this->render(); } public function postDispatch() { } }
Présentons rapidement ce script PHP
C'est une classe qui hérite de Zend_Controller_Action
, une classe de framework.
init: appelé une seule fois, à l'instanciation de la classe (à l'image d'un constructeur)
preDispatch: appelé avant un appel automatique à une méthode d'action
xxAction : des méthodes d'action
postDispatch: appelé après un appel automatique à une méthode d'action
Il est important de comprendre que vous ne ferez quasiment jamais appel explicitement à ces méthodes ! elles font partie de la logique du framework, et c'est ce dernier qui prend en charge les appels.
Votre rôle, en tant que développeur, consiste à définir (concevoir, déclarer) les bonnes classes, les bonnes méthodes.
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 CountryController
:
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/country/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.
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.
ZFQuickstart |-- application | |-- controllers | | |--CountryController.php | | | |-- models | `-- views | | |--scripts | | | |--country | | | | |--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/country/index.phtml :
<h1>Les pays</h1>
Sollicitons de nouveau notre contrôleur CountryController
:
Nous avons vu :
Comment concevoir, par héritage, un contrôleur de cas d'utilisation.
Comment solliciter, par l'URL, une action d'un contrôleur de cas d'utilisation.
Comment associer une vue à une action du contrôleur
Cas particuliers
Le contrôleur, après traitement, n'a pas de donnée à transmettre à la vue :
=> il peut « passer la main » à une autre méthode d'action :
... public function supprimerAction() { ... $this->_forward('index'); // soustraite (renvoi) à une autre action de ce contrôleur }
La vue n'attend rien du contrôleur. Pas de problème, c'est ce que nous avons fait jusqu'à présent.
Sélection d'une autre vue (liée au même contrôleur) que celle basée sur le nom de l'action : $this->render('autrevue');
- plus d'infos ici zend.controller.action.html
Contrôleurs et Vues sont liés par contrat. Le contrôleur passe des données à la vue, cette dernière doit en connaître la nature, c'est à dire le « nom » et le « type associé ».
Le contrôleur passera un objet de type "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 coder le contrôleur :
require_once('Country.php'); class CountryController extends Zend_Controller_Action { public function init() { } 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 $ct = new Country($db); // obtenons un objet Zend_Db_Select (capable d'appliquer des restrictions) $select = $ct->select(); // aucune clause where, donc cette variable est inutile ici // nous transmettons sous le nom 'countries' à la vue l'ensemble // des lignes de la table Country soit un objet Zend_Db_Table_Rowset // (colection d'objets CountryRow - des Zend_Db_Table_Row) $this->view->countries=$ct->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 $ct = new Country($db); //AVEC connexion par défaut (une seule instruction !) // Aucun argument à la construction. // Liaison automatique via la connexion par défaut $ct = new Country(); $this->view->countries=$ct->fetchAll(); |
Le script de la vue associé à l'action est : views/country/index.phtml
.
En effet, les attributs automatiques de notre modèle sont directement accessibles (non privés).
<table> <?php foreach ($this->countries as $country) : ?> <tr> <td> <?php echo $this->escape($country->id) ?> </td> <td> <?php echo $this->escape($country->Name) ?> </td> <td> <?php echo $this->escape($country->Continent) ?> </td> <td> <?php echo $this->escape($country->LocalName) ?> </td> </tr> <?php endforeach; ?> </table>
Ce script utilise la méthode « escape » pour échapper les caractères (Par défaut, la méthode escape() utilise la fonction PHP htmlspecialchar() pour l'échappement).
A noter la syntaxe à la « endif », voir doc syntaxe PHP qui favorise la lecture (les accolades ouvrantes et fermantes sont parfois difficiles à repérer dans la vue).
Ce script de vue exploite une collection d'objets de type Country.
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 countries, une collection
d'objets de type Country
.
Remarque : Dans cette configuration, Contrôleur et Vue sont dépendants du Modèle.
On a vu :
Les devoirs du contrôleur, de la vue.
Les droits de la vue (ceux du contrôleur étant liés aux données reçues ainsi qu'au modèle)
La façon dont le contrôleur passe des données à la vue.
La façon dont la vue exploite des données.
... et pour les plus observateurs, la façon d'envoyer des données de débogage (Zend_Debug::dump).
Nous souhaitons ne pouvoir consulter qu'un seul pays à la fois (et non une liste comme précédemment) .
![]() | Autre service -> autre UC |
---|---|
Nous considérons cette demande comme un nouveau cas d'utilisation du système spécifique au contrôleur Nous concevons alors une nouvelle méthode d'action : |
Par convention, les noms capitalisés sont associés à des noms où les caractères majuscule sont remplacés par le caractère minuscule correspondant précédé d'un tiret (voir doc ici).
:action: MixedCase and camelCasedWords are separated by dashes; non-alphanumeric characters are translated to dashes, and the entire string cast to lower case. Examples: "fooBar" becomes "foo-bar"; "foo-barBaz" becomes "foo-bar-baz".
Fichier voir-pays.phtml
<style type="text/css"> <!-- .pays { margin-left: 40px; } --> </style> <div class='pays'> <h2>Pays</h2> Pays : <?= $this->pays->Name ?> <br> Continent : <?= $this->pays->Continent ?> <br> Nombre de villes inscrites : <?= $this->pays->getNbCities() ?> <br> </div>
Le problème se pose côté contrôleur : Quel pays transmettre à la vue ?
Le service devra donc être paramétré. Le contrôleur attend donc une donnée lui permettant de déterminer le bon pays à transmettre à la vue. Par défaut le contrôleur transmettre le premier de la liste (id=1).
Voici la méthode d'action en charge de ce cas d'utilisation du contrôleur CountryController
:
public function voirPaysAction() { if ($this->_hasParam('id')) $index = $this->_getParam('id'); else $index = 1; $ct = new Country(); $pays = $ct->find($index)->current(); $this->view->pays=$pays; $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 pays (index=1), sinon, elle utilise directement la valeur reçue index (très dangereux, à ne pas reproduire !)
Nous obtenons :
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:// ... /zf-tuto/country/voir-pays/id/1
Équivalent à :
http:// ... /zf-tuto/country/voir-pays?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 un autre pays (id=3)
Enfin, voici les liens logiques liant les éléments de la requête et le contrôleur.
Avant d'interagir avec le modèle, et maintenant que vous avez compris l'essentiel (rôle d'une vue, d'un contrôleur, passage d'arguments), vous réaliserez les cas d'utilisation suivant:
Permettre à un utilisateur de consulter les caractéristiques d'UN pays.
Prévoir une nouvelle action :
http:// ... /zf-tuto/country/voir-details
Permettre à un utilisateur, lorsqu'il consulte les caractéristiques d'UN pays, de naviguer vers le prochain ou le précédent.
Prévoir une nouvelle action :
http:// ... /zf-tuto/country/voir-details-nav
Indication : la vue dispose d'une méthode, nommée url
, prenant en argument
un tableau associatif spécifiant des composantes ZF-MVC de l'url. Exemple :
// dans un script de vue .phtml ... <a href='<?=$this->url(array('controller'=> 'index' , 'action'=> 'lister' , 'param1' => 'valParam1' , 'param2' => 'valParam2'));?>'>un lien</a> ... // produit la sortie : // <a href='http://.../index/lister/param1/valParam1/param2/valParam2'>un lien<a>
La difficulté consiste à trouver le moyen de sélectionner le prochain (et le précédent) pays correspondant au pays courant, car il peut y avoir des "trous" dans les valeurs d'id (en cas de suppression par exemple). Ci-dessous, quelques éléments qui pourrait bien vous donner des idées de solution :
... // on retrouve le registre global $registry = Zend_Registry::getInstance(); // et notre connexion $db = $registry->get('db'); $this->index = $this->_getParam('id', 1); $pt = new Country($db); $pays = $pt->find($this->index)->current(); //Recuperation de l'id max $max = $db->fetchOne('SELECT MAX(id) as id FROM Country');
Vous trouverez ici : le rôle de fetchOne
.
Reprendre l'exercice précédent mais ne pas proposer à l'utilisateur la possibilité de naviguer avant le premier et après le dernier pays.
Indication : Conformément au paradigme MVC, on veillera à ne pas charger la vue en responsabilité (métier/technique).
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 :
Recherche le pays d'id = 1
// Fontion de niveau 'table' $dt = new Country(); $pays = $dt->find(1)->current();
La méthode find
prend comme argument un identifiant (un ou plusieurs arguments selon le cas), et retourne un Rowset
.
La méthode current
d'un Rowset
retourne l'élément courant sous la
forme d'un objet Row
(ou NULL
s'il n'existe pas. Dans notre cas c'est le premier et unique CountryRow
.
Modification de l'attribut 'HeadOfState' du pays d'id = 73
// Fontion de niveau 'tuple' $dt = new Country(); $rowPays = $dt->find(73)->current(); // en 2006, $rowPays->HeadOfState == 'Jacques Chirac' $rowPays->HeadOfState = "Nicolas Sarkozy"; $rowPays->save();
La méthode save
fait une mise à jour, dans la table Country
, du tuple associé à notre objet.
création d'une ville
public function testAddAction(){ require_once 'City.php'; // Fontion de niveau 'table' et 'tuple' $ct = new City(); // les données sont représentées par un dictionnaire $data = array( 'Name' => 'Test', 'LocalName' => 'local test', // pays concerné, car il en faut un. 'idCountry' => 2, 'District' => 'regionTest', 'Population' => 1 // pas grand monde ); $cityRow=$ct->createRow($data); // Zend_Debug::dump($cityRow); if ($cityRow) { $id=$cityRow->save(); // Ok, c'est fait ! // en extra, on zappe de méthode d'action, afin de visualiser le résultat // passage en argument de l'id du pays concerné par ce test $this->_setParam('id','2'); // sous-traitance de service (function villesAction de ce // contrôleur, présentée un peu plus loin dans ce doc) $this->_forward('villes'); } }
La méthode createRow
crée un CityRow en mémoire.
La méthode save
tente d'insérer le nouveau tuple dans la table City
.
suppression d'une (ou des) ville(s) portant le nom 'Test'
// Opération de niveau 'table' public function testDeleteAction(){ require_once 'City.php'; $ct = new City(); $where = $ct->getAdapter()->quoteInto('Name = ?', 'Test'); // suppression dans la table $ct->delete($where); // en extra, on zappe de méthode d'action, afin de visualiser le résultat // passage en argument de l'id du pays concerné par ce test (voir testAddAction) $this->_setParam('id','2'); $this->_forward('villes'); }
La méthode delete
supprime, de la table City, le ou les tuples filtrés par la clause 'where'.
On se réfère à la connexion pour gérer une transaction :
$db = Zend_Registry::get('dbAdapter'); $db->beginTransaction(); try { // insert pays [...] // insert pays avec une clé primaire erronée $data = array( 'id' => 1, 'Name' => 'France', ... ); $ct = new Country(); $ct->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('/'); }
le manuel en ligne, de qualité : Zend_Db
des fonctions illustrées d'accès aux données Wiki Zend_Db
Une présentation du lien entre logique du modèle et table : http://zend-framework.developpez.com/
L'API Zend_Db_Table and Co
Nous nous intéressons ici aux relations entre les entités du modèle, entre les objets de type Table_Row
.
La phase préliminaire consiste à déclarer les relations dans les définitions des Classes de niveau Table.
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'
//City.php <?php //Country.php <?php class Country extends Zend_Db_Table_Abstract { protected $_name = 'Country'; protected $_primary = 'id'; protected $_rowClass = 'CountryRow'; protected $_referenceMap = array( 'Capitale' => array( 'columns' => 'Capital', 'refTableClass' => 'City', 'refColumns' => 'id' )); } //City.php <?php class City extends Zend_Db_Table_Abstract { protected $_name = 'City'; protected $_primary = 'id'; protected $_rowClass = 'CityRow'; protected $_referenceMap = array( 'MonPays' => array( 'columns' => 'idCountry', 'refTableClass' => 'Country', 'refColumns' => 'id' )); } //CountryLanguage.php <?php class CountryLanguage extends Zend_Db_Table_Abstract { protected $_name = 'CountryLanguage'; protected $_primary = array('idCountry', 'idLanguage'); protected $_referenceMap = array( 'Langue' => array( 'columns' => array('idLanguage'), 'refTableClass' => 'Language', 'refColumns' => array('id') ), 'Pays' => array( 'columns' => array('idCountry'), 'refTableClass' => 'Country', 'refColumns' => array('id') ) ); } // la notation 'tableau' montre comment opérer en cas de clés multi-attributs ('id', ou 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 :
Un nom : par exemple 'Pays'
La ou les colonnes de la clé (éventuellement composée) : par exemple array('idCountry')
La classe correspondant à la table référencée : par exemple 'Country"
La ou les colonnes correspondant dans la table référencée : par exemple array('id')
Une cas typique consiste à exploiter le tuple associé à une clé étrangère. Par exemple, dans le tableau qui liste les pays, nous souhaiterions voir apparaître, non pas l'identifiant de la capitale, mais son nom.
Actuellement le code de la vue est :
<table> <?php foreach ($this->countries as $country) : ?> <tr> <td> <?php echo $this->escape($country->id) ?> </td> <td> <?php echo $this->escape($country->Name) ?> </td> <td> <?php echo $this->escape($country->Continent) ?> </td> <td> <?php echo $this->escape($country->LocalName) ?> </td> <td> <?php echo $this->escape($country->Capital) ?> </td> </tr> <?php endforeach; ?> </table>
Nous souhaitons afficher le nom de la capitale, à la place de son identifiant.
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 pays qui connaît sa capitale », nous nous adresserons donc à ce dernier.
<?php
<?php foreach ($this->countries as $country) : ?>
<tr>
<td> <?php echo $this->escape($country->id) ?> </td>
<td> <?php echo $this->escape($country->Name) ?> </td>
<td> <?php echo $this->escape($country->Continent) ?> </td>
<td> <?php echo $this->escape($country->LocalName) ?> </td>
<td> <?php echo $this->escape($country->getCapitale()->Name) ?> &bnsp; </td>
<td> <a href=''> les villes </a> </td>
</tr>
<?php endforeach; ?>
}
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
:
<?php class CountryRow extends Zend_Db_Table_Row_Abstract { public function getCapitale() { $city = $this->findParentRow('City', 'Capitale'); // les arguments de findParentRow : // 'City' -> c'est la table // 'Capitale' -> c'est le rôle défini dans $_referenceMap de County.php return $city; } public function getNbCities(){ // TODO return -1; } } ?>
La méthode findParentRow
exploite les données de $_referenceMap
pour
sélectionner la ligne (Row) de la table City
liée à l'instance
courante (relative à une ligne de la table Country
).
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 :
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 villes référencées dans la base de données pour un pays donné.
Plusieurs alternatives s'offrent à nous :
Concevoir, dans le contrôleur, une requête du genre :
$db = Zend_Registry::get('dbAdapter'); $sql = "SELECT v.Name, v.District, v.Population FROM Country c, City v WHERE c.id = v.idCountry AND c.id = ?"; $sql = $db->quoteInto($sql, $idDplome); $inscrits = $db->fetchAll($sql); ...
Reléguer cette responsabilité à Country
$ct = new Country(); $pays = $ct->find($idPays)->current(); $inscrits = $pays->getVilles();
Dans le respect du pattern Expert en Information, nous choisirons la deuxième solution.
Comme vous l'avez certainement constaté , le lien nommé 'voir les villes' : <a href='villes/id/$pays->id'>voir</a> fait référence à une méthode d'action du contrôleur courant 'country', que nous devons concevoir. Mais intéressons-nous en premier à sa vue :
Fichier : views/script/country/villes.phtml
<style>
<!--
table,th,td {
border-style: solid;
border-width: 1px;
}
table,caption {
margin-left: auto;
margin-right: auto;
width: auto;
}
-->
</style>
<table>
<caption>Les villes du pays >?php echo =$this->nomPays; ?></caption>
<thead>
<tr>
<th>Ville</th>
<th>Région</th>
<th>Population</th>
</tr>
</thead>
<tbody>
<?php foreach ($this->villes as $ville) : ?>
<tr><td> <?php echo $ville->Name; ?> </td>
<td> <?php echo $ville->District ?> </td>
<td> <?php echo $ville->Population ?> </td>
</tr>
<?php endforeach; ?>
</tbody>
</table>
Cette vue part du principe qu'elle dispose, dans son contexte d'exécution,
de deux attributs : $nomPays
et une liste de villes $villes
Voyons comment ces informations lui sont transmises.
La vue s'appelant villes.phtml
, notre méthode action sera villesAction
:
//CountryController.php public function villesAction() { $idPays=$this->_getParam('id', 1); $ct = new Country(); $paysRow = $ct->find($idPays)->current(); $villes=$paysRow->getVilles(); $this->view->villes=$villes; $this->view->nomPays=$paysRow->Name; $this->render(); }
Les différentes étapes
La méthode commence par obtenir la valeur du paramètre de la requête, avec une valeur par défaut (pays=1)
Un objet de type Country
est crée.
... à partir duquel une requête est lancée, afin d'obtenir une instance de CountryRow
.
Nous obtenons, à partir d'un pays, l'ensemble des villes
... et le nom du pays
Le tout est transmis à la vue
... qui prend le relai (render
)
Sur cette base nous pouvons implémenter la méthode getVilles
de la classe CountryRow
.
Pour cela nous utiliserons la méthode findDependanteRowset
héritée de la classe Zend_Db_Table_Row_Abstract
:
Cette méthode permet d'obtenir l'ensemble des tuples d'une table référencant le tuple courant.
Soit :
<?php
class CountryRow extends Zend_Db_Table_Row_Abstract {
public function getVilles() {
return $this->findDependentRowset('City');
}
public function getCapitale() {
$city = $this->findParentRow('City', 'Capitale');
// les arguments de findParentRow :
// 'City' -> c'est la table
// 'Capitale' -> c'est le rôle défini dans $_referenceMap de County.php
return $city;
}
public function getCapitaleBis() {
$db = $this->getTable()->getAdapter();
// ou : -- voir index.php
// $registry = Zend_Registry::getInstance();
// $db = $registry.get('db');
$res = $db->query("SELECT * FROM City WHERE id = ?", array($this->Capital));
require_once('CityRow.php');
$city = new CityRow();
$res->setFetchMode(PDO::FETCH_INTO, $city );
$city = $res->fetchObject();
return $city;
}
public function getVillesBis() {
// "SELECT * FROM City WHERE id = ?", array($this->id)
}
public function getNbCities(){
// 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 CityRow
(relatifs aux lignes) lignes de la table City
qui sont en relation avec this
.
![]() | Le rôle des relations |
---|---|
La méthode return $this->findDependentRowset('City', 'MonPays'); |
Cas d'une table relation porteuse ou non de propriétés
Une table relation, connue également sous l'appellation table intersection
, est une table dont la principale raison
d'être est de mettre en relation deux tuples (d'une même table ou de tables différentes).
La clé étrangère d'une des deux tables est systématiquement "déréférencées".
Zend Framework fournit une façon directe d'exploiter des tables relation.
Prenons un exemple, si nous avions voulu prendre connaissance des pays où la langue française est parlée, tout en en connaissant en connaître les détails
(officielle ou non, pourcentage parlé). C'est à dire que nous souhaitons obtenir la listes des pays (objet CountryRow
) via CountryLanguageRow
:
// LanguageRow.php // obtenir tous les pays parlant cette langue public function getPaysParlantCetteLangue() { return $this->findManyToManyRowset('Country', 'CountryLanguage'); }
Nous utilisons ici la table relation « CountryLanguage » côté « Country » (prendre les informations des deux tables).
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).
Voici un exemple d'utilisation : L'utilisateur demande la liste des pays où la langue française est représentée :
Puis l'utilisateur souhaite connaître les langues référencées pour un pays donné :
Les actions du controleur :
public function languesAction() { $idPays=$this->_getParam('id', 1); $ct = new Country(); $paysRow = $ct->find($idPays)->current(); $langues=$paysRow->getLanguesParlees(); $this->view->langues=$langues; $this->view->nomPays=$paysRow->Name; $this->render(); } public function paysLangueAction() { $idLangue=$this->_getParam('idlangue', 1); //Zend_Debug::dump($this->getRequest()->getParams()); $lt = new Language(); $languageRow = $lt->find($idLangue)->current(); $lesPays=$languageRow->getPaysParlantCetteLangue(); $this->view->lesPays=$lesPays; $this->view->nomLangue=$languageRow->Name; $this->render(); }
Les vues associées :
//pays-langue.phtml <table> <caption>Pays ayant comme langue parlée: <?php echo $this->nomLangue ?></caption> <thead> <tr> <th>Pays</th> <th>Officielle</th> <th>Pourcentage</th> </tr> </thead> <tbody> <?php foreach ($this->lesPays as $pays) : ?> <tr> <td> <?php echo $pays->Name; ?> </td> <td> <?php echo $pays->IsOfficial; ?> </td> <td> <?php echo $pays->Percentage; ?> </td> </tr> <?php endforeach; ?> </tbody> </table>
//langues.phtml table> <caption>Les langues parlées du pays <?php echo $this->nomPays ?></caption> <thead> <tr> <th>Langue</th> <th>Officielle</th> <th>Pourcentage</th> <th>autres pays</th> </tr> </thead> <tbody> <?php foreach ($this->langues as $langue) : ?> <tr> <td> <?php echo $langue->Name; ?> </td> <td> <?php echo $langue->IsOfficial; ?> </td> <td> <?php echo $langue->Percentage; ?> </td> <td> <a href='<?php echo $this->url(array('controller'=>'country', 'action'=>'pays-langue', 'idlangue'=> $langue->idLanguage), null, true) ?>'>voir</a> </td> </tr> <?php endforeach; ?> </tbody> </table>
Les méthodes de niveau Row
//LanguageRow.php <?php class LanguageRow extends Zend_Db_Table_Row_Abstract { // obtenir tous les pays parlant cette langue public function getPaysParlantCetteLangue() { return $this->findManyToManyRowset('Country', 'CountryLanguage'); } }
//CountryRow.php public function getLanguesParlees() { return $this->findManyToManyRowset('Language', 'CountryLanguage'); }
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
// CountryRow.php
...
public function getVilles() {
//return $this->findDependentRowset('City', 'MonPays');
return $this->findCity();
}
...
sera interprété : $this->findDependentRowset('City')
Il en va de même avec les méthodes de type « findTableViaTableRelation » quie seront traduites avec findManyToManyRowset
: Exemple
// CountryRow.php
public function getLanguesParlees() {
//return $this->findManyToManyRowset('Language', 'CountryLanguage');
return $this->findLanguageViaCountryLanguage();
}
...
Plus d'information avec le guide du développeur et l'API
Comme tout framework qui se repecte, ZF propose des composants dédiées aux formulaires des applications Web.
ZF propose l'API Zend_Form
, associé à Zend_Validate, Zend_Filter
pour la
création et la gestion des formulaires (présentation, validation, retour au client).
Nous allons permettre la modification d'une donnée associée à Country
, à savoir l'attribut « HeadOfState ».
Nous mettons en place un lien de modification dans la vue en liste.
Le lien 'modifier' pointe sur country/edit
. Nous créons donc une méthode d'action associée.
public function editAction() { $this->view->title = "Modifier pays"; $form = new PaysForm(); // ... $this->view->form = $form; }
Un formulaire est un peu plus qu'une vue, il permet à l'utilisateur de transmettre de multiples informations issues de listes déroulantes, cases à cocher, champs d'édition de texte...
De plus, les données d'un formulaire doivent être filtrées (pour se prémunir d'actions dangereuses) et validées (pour assurer la cohérence des données), ceci pouvant entraîner des aller/retour entre le serveur et le client.
Ce type de comportement est pré-programmé par ZF, et pour en hériter, nous devons faire ... hériter nos formulaires de Zend_Form
.
La classe PaysForm
hérite de Zend_Form
. Remarque : Cette classe de base prend en compte bien d'autres aspects, voir ici Zend_Form .
Le formulaire PaysForm.php est à placer dans /application/forms
:
<?php class PaysForm extends Zend_Form { public function __construct($options = null) { parent::__construct($options); $this->setName('modifierpays'); $headstate = new Zend_Form_Element_Text('HeadOfState'); $headstate->setLabel('HeadOfState') ->setRequired(true) ->addValidator('NotEmpty'); $headstate->addValidator(new Zend_Validate_StringLength(3)); $id = new Zend_Form_Element_Hidden('id'); $submit = new Zend_Form_Element_Submit('submit'); $submit->setLabel('Modifier'); $this->addElements(array($headstate, $id, $submit)); } }
Quelques explications :
Le constructeur se charge de la structure du formulaire, élément par élément.
Des contrôles HTML de type input='text' sont créés via Zend_Form_Element_Text
Les champs de saisis requis sont spécifiés (required
)
A chacun des contrôles d'entrée sont associés filtres, validateurs et vue
A titre d'indication, on trouvera ici une liste des éléments standards définis par ZF. Exemples : Button, Checkbox, Hidde, Image, MultiCheckbox, Multiselect, Password, Radio, Reset, Select, Submit, Text, Textarea et Zend_Form_Element_Hash pour augmenter la sécurité.
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 :
$headstate = new Zend_Form_Element_Text('HeadOfState'); $headstate->setLabel('HeadOfState'); $headstate->setRequired(true); $filter = new Zend_Filter_StripTags(); $headstate->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 :
$headstate = new Zend_Form_Element_Text('HeadOfState'); $headstate->setLabel('HeadOfState'); $headstate->setRequired(true); $headstate->addValidator(new Zend_Validate_NotEmpty());
Les validateurs peuvent être chainés :
... $headstate->addValidator(new Zend_Validate_StringLength(2)); $headstate->addValidator(new Zend_Validate_Alnum()); // ou $headstate->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).
$form = new PaysForm(); // instanciation du formulaire
if ($this->_request->isGet()) {
$id = $this->_getParam('id', -1);
if ($id == -1)
// rien à faire ici
return $this->_helper->redirector('index', 'country');
$ct=new Country();
$rowPays=$ct->find($id)->current();
if ($rowPays) {
// initialisation du formulaire
// Zend_Debug::dump($rowPays);
$form->getElement('HeadOfState')->setValue($rowPays->HeadOfState);
$form->getElement('id')->setValue($rowPays->id);
}
}
// reception de donnees ?
else if ($this->_request->isPost()) {
$formData = $this->_request->getPost();
// nous les affectons au formulaire
$form->populate($formData);
// qui applique les filtres
$formData=$form->getValues();
$ct=new Country();
$rowPays=$ct->find($formData['id'])->current();
// activation des validateurs
if ($rowPays && $form->isValid($formData)) {
// ok, nous pouvons opérer
$rowPays->HeadOfState = $formData['HeadOfState'];
// sauvegarde dans la BD
$id=$rowPays->save();
// make a "redirect after post"
// @see http://en.wikipedia.org/wiki/Post/Redirect/Get
return $this->_helper->redirector('index', 'country');
}
}
// présentation du formulaire
if ($rowPays) {
$this->view->action = "Modifier le nom du chef d'état";
$this->view->pays = $rowPays->Name;
$this->view->form = $form;
$this->render();
}
else {
//sinon, rien à faire ici !
return $this->_helper->redirector('index', 'country');
}
}
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.
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
Espérons que ce document vous ait permis d'apprécier le fort potentiel d'un framework en application Web : productivité, robustesse, extensibilité, maintenabilité, sécurité, ... Même si ces qualités n'ont été qu'effleurées.
Vous pouvez maintenant vous intéresser au quickstart en ligne, vous y découvrirez une utilisation plus avancée du modèle, et une construction plus structurée des vues car ces dernières (dans ce tuto) ce ne sont que des blocs de doc HTML.
Vous trouverez ici une implémentation simple de ce tuto, avec un début d'intégration d'un layout
: tuto.zip ALL IN ONE (5.5Mo) - la base de données est à installer puis les
valeurs database.params.xxx
de application.ini
. devront être renseignées en conséquence.
Le quick start de ZF, chez Zend..
Le guide du développeur, de très bonne qualité et mis à jour régulièrement.
Site officiel : zend france