Première partie – Programmation web avec MySQL/PHP
Chapitre 1 – Introduction à MySQL et PHP
1.1 Introduction au Web et à la programmation web
1.1.1 Serveurs web
1.1.2 Documents web : le langage XHTML
1.1.3 Programmation web
1.1.4 Sessions
1.2 Programmation web avec MySQL et PHP
1.2.1 MySQL
1.2.2 PHP
1.3 Une première base MySQL
1.3.1 Création d'une table
1.3.2 L'utilitaire mysql
1.3.3 L'interface PhpMyAdmin
1.4 Accès à MySQL avec PHP
1.4.1 L'interface MySQL/PHP
1.4.2 Formulaires d'interrogation
1.4.3 Formulaires de mises à jour
Chapitre 2 – Techniques de base
2.1 Programmation avec fonctions
2.1.1 Création de fonctions
2.1.2 Utilisation des fonctions
2.1.3 À propos de require et include
2.1.4 Passage par valeur et passage par référence
2.2 Traitement des données transmises par HTTP
2.2.1 Échappement et codage des données HTTP
2.2.2 Contrôle des données HTTP
2.2.3 Comment insérer dans la base de données : insertion dans MySQL
2.2.4 Traitement de la réponse
2.2.5 Comment obtenir du texte « pur » : envoi de l'e-mail
2.2.6 En résumé : traitement des requêtes et des réponses
2.3 Mise à jour d'une base par formulaire
2.3.1 Script d'insertion et de mise à jour
2.3.2 Validation des données et expressions régulières
2.4 Transfert et gestion de fichiers
2.4.1 Transfert du client au serveur
2.4.2 Transfert du serveur au client
2.5 Sessions
2.5.1 Comment gérer une session web ?
2.5.2 Gestion de session avec cookies
2.5.3 Prise en charge des sessions dans PHP
2.6 SQL dynamique et affichage multi-pages
2.6.1 Affichage d'une requête dynamique
2.6.2 Affichage multi-pages
Chapitre 3 - Programmation objet
3.1 Tour d'horizon de la programmation objet
3.1.1 Principes de la programmation objet
3.1.2 Objets et classes
3.1.3 Les exceptions
3.1.4 Spécialisation : classes et sous-classes
3.1.5 Spécialisation et classes abstraites : la classe BD
3.1.6 Résumé
3.2 La classe Tableau
3.2.1 Conception
3.2.2 Utilisation
3.2.3 Implantation
3.3 La classe Formulaire
3.3.1 Conception
3.3.2 Utilisation
3.3.3 Implantation
3.4 La classe IhmBD
3.4.1 Utilisation
3.4.2 Implantation
Deuxième partie – Conception et création d’un site
Chapitre 4 – Création d'une base MySQL
4.1 Conception de la base
4.1.1 Bons et mauvais schémas
4.1.2 Principes généraux
4.1.3 Création d'un schéma E/A
4.2 Schéma de la base de données
4.2.1 Transcription des entités
4.2.2 Associations de un à plusieurs
4.2.3 Associations de plusieurs à plusieurs
4.3 Création de la base Films avec MySQL
4.3.1 Tables
4.3.2 Contraintes
4.3.3 Modification du schéma
Chapitre 5 – Organisation du développement
5.1 Choix des outils
5.1.1 Environnement de développement intégré Eclipse
5.1.2 Développement en équipe : Subversion
5.1.3 Production d'une documentation avec PhpDoc
5.1.4 Tests unitaires avec PhpUnit
5.1.5 En résumé
5.2 Gestion des erreurs
5.2.1 Erreurs syntaxiques
5.2.2 Gestion des erreurs en PHP
5.2.3 Les exceptions PHP
5.2.4 Gestionnaires d'erreurs et d'exceptions
5.3 Portabilité multi-SGBD
5.3.1 Précautions syntaxiques
5.3.2 Le problème des séquences
5.3.3 PDO, l'interface générique d'accès aux bases relationnelles
Chapitre 6 – Architecture du site : le pattern MVC
6.1 Le motif de conception MVC
6.1.1 Vue d'ensemble
6.1.2 Le modèle
6.1.3 La vue
6.1.4 Contrôleurs et actions
6.1.5 Organisation du code et conventions
6.2 Structure d'une application MVC : contrôleurs et actions
6.2.1 Le fichier index.php
6.2.2 Le contrôleur frontal
6.2.3 Créer des contrôleurs et des actions
6.3 Structure d'une application MVC : la vue
6.3.1 Les templates
6.3.2 Combiner des templates
6.3.3 Utilisation d'un moteur de templates comme vue MVC
6.3.4 Exemple complet
6.3.5 Discussion
6.4 Structure d'une application MVC : le modèle
6.4.1 Modèle et base de données : la classe TableBD
6.4.2 Un exemple complet de saisie et validation de données
6.4.3 Pour conclure
Chapitre 7 – Production du site
7.1 Authentification
7.1.1 Problème et solutions
7.1.2 Contrôleur d'authentification et de gestion des sessions
7.1.3 Les actions de login et de logout
7.2 Recherche, présentation, notation des films
7.2.1 Outil de recherche et jointures SQL
7.2.2 Notation des films
7.3 Affichage des films et forum de discussion
7.4 Recommandations
7.4.1 Algorithmes de prédiction
7.4.2 Agrégation de données avec SQL
7.4.3 Recommandations de films
Chapitre 8 – XML
8.1 Introduction à XML
8.1.1 Pourquoi XML ?
8.1.2 XML et HTML
8.1.3 Syntaxe de XML
8.2 Export de données XML
8.2.1 Comment passer d'une base MySQL à XML
8.2.2 Application avec PHP
8.3 Import de données XML dans MySQL
8.3.1 Simple XML
8.3.2 L'API SAX
8.3.3 Une classe de traitement de documents XML
8.4 Mise en forme de documents avec XSLT
8.4.1 Quelques mots sur XSLT
8.4.2 Application d'un programme XSLT avec PHP
Troisième partie – Compléments
Chapitre 9 – Introduction au Zend Framework
9.1 Mise en route
9.1.1 Installation d'une application ZF
9.1.2 Redirection des requêtes avec le ZF
9.1.3 Organisation et conventions
9.1.4 Routage des requêtes dans une application Zend
9.1.5 Configuration
9.1.6 Connexion à la base de données
9.1.7 Le registre
9.1.8 Contrôleurs, actions et vues
9.2 Accès à la base de données
9.2.1 Interrogation
9.2.2 Insertion et mise à jour
9.3 Le MVC du Zend Framework
9.3.1 L'objet request
9.3.2 L'objet response
9.3.3 Gérer les exceptions
9.4 La vue dans le Zend Framework
9.4.1 Les vues sont des scripts PHP
9.4.2 Le layout
9.4.3 Créer des Helpers
9.5 Le composant Modèle du Zend Framework
9.5.1 L'ORM du Zend Framework
9.5.2 Le modèle ORM de l'application
9.5.3 Manipulation des données avec les classes ORM
9.6 Pour conclure
Chapitre 10 – Récapitulatif SQL
10.1 Sélections
10.1.1 Renommage, fonctions et constantes
10.1.2 La clause DISTINCT
10.1.3 La clause ORDER BY
10.1.4 La clause WHERE
10.1.5 Dates
10.1.6 Valeurs nulles
10.1.7 Clauses spécifiques à MySQL
10.2 Jointures
10.2.1 Interprétation d'une jointure
10.2.2 Gestion des ambiguïtés
10.2.3 Jointures externes
10.3 Opérations ensemblistes
10.4 Requêtes imbriquées
10.4.1 Exemples de requêtes imbriquées
10.4.2 Requêtes corrélées
10.4.3 Requêtes avec négation
10.5 Agrégation
10.5.1 La clause GROUP BY
10.5.2 La clause HAVING
10.6 Mises à jour
10.6.1 Insertion
10.6.2 Destruction
10.6.3 Modification
Chapitre 11 – Récapitulatif PHP
11.1 Généralités
11.1.1 Commentaires
11.1.2 Variables et littéraux
11.1.3 Constantes
11.2 Types
11.2.1 Types numériques et booléens
11.2.2 Chaînes de caractères
11.2.3 Tableaux
11.2.4 Conversion et typage
11.3 Expressions
11.4 Opérateurs
11.4.1 Concaténation de chaînes
11.4.2 Incrémentations
11.4.3 Opérateurs de bits
11.4.4 Opérateurs logiques
11.5 Structures de contrôle
11.5.1 Tests
11.5.2 Boucles
11.5.3 Les instructions break et continue
11.6 Fonctions
11.6.1 Passage des arguments
11.6.2 Valeurs par défaut
11.6.3 Fonctions et variables
11.7 Programmation orientée-objet
11.7.1 Classes et objets
11.7.2 Constructeurs et destructeurs
11.7.3 Sous-classes
11.7.4 Manipulation des objets
11.7.5 Compléments
Quatrième partie – Annexes
Annexe A – Installation Apache/PHP/MySQL
A. 1 Mot de passe root
A. 2 Création de bases et d'utilisateurs
A. 2.1 La commande GRANT
A. 2.2 Modification des droits d'accès
A. 3 Fichiers de configuration
A. 3.1 Format d'un fichier de configuration
A. 3.2 Les différents fichiers
A. 3.3 Configuration du serveur
A. 3.4 Configuration d'un compte administrateur
A. 4 Sauvegardes
A. 5 phpMyAdmin
Annexe B – Référence MySQL
B. 1 Types de données MySQL
B. 2 Commandes de MySQL
B. 3 Fonctions MySQL
Annexe C – Fonctions PHP
C. 1 Fonctions générales
C. 2 Chaînes de caractères
C. 3 Dates
C. 4 Tableaux
C. 5 Fonctions XML
C. 6 Accès aux fichiers
C. 7 Interface PHP/MySQL
Index général
Index des fonctions PHP
Index des commandes SQL
Table des figures
Nội dung
9.1 Mise en route 363 Il est temps d’inspecter le fichier index.php, nommé bootstrap file,oufichier d’amor- çage, qui se charge d’initialiser l’application et de déclencher le processus de rou- tage. Exemple 9.1 zscope/www/index.php : Le fichier d’amorçage de l’application ZScope <?php // On affiche toutes les erreurs error_reporting(E_ALL | ~E_STRICT) ; // On recherche le chemin d’accès à ZScope $root = dirname( dirname(__FILE__)) . DIRECTORY_SEPARATOR ; // On ajoute le chemin d’accès au ZF set_include_path(dirname( $ r o o t ) . DIRECTORY_SEPARATOR . ’ ZF ’ . DIRECTORY_SEPARATOR . PATH_SEPARATOR . g e t _ i n c l u d e _ p a t h ( ) ); // Ajout des chemins d’accès aux composants de l ’application set_include_path( ’ . ’ . PATH_SEPARATOR . $ r o o t . ’ a p p l i c a t i o n ’ . DIRECTORY_SEPARATOR . ’ m o d e l s ’ . DIRECTORY_SEPARATOR . PATH_SEPARATOR . g e t _ i n c l u d e _ p a t h ( ) ); // On utilise toujours le loader automatique require_once ’Zend/ Loader.php ’ ; Zend_Loader :: registerAutoload(); // On lit le fichier de configuration $config = new Zend_Config_Ini(" / application / config . ini " , " staging"); ini_set( ’display_errors ’ , $config−>app−>display_errors); date_default_timezone_set($config−>app−>default_timezone); // Connexion à la base de données $db = Zend_Db:: factory($config−>db) ; // Cette connexion est à ut i l i s er pour le Modèle Zend_Db_Table :: setDefaultAdapter($db); // On ajoute la configuration et la connexion // au registre de l ’application $registry = Zend_Registry :: getInstance () ; $registry−>set ( ’ config ’ , $config) ; $registry−>set ( ’db ’ , $db) ; // Initialisation et exécution d’un contrôleur frontal try { $front = Zend_Controller_Front :: getInstance() ; // $front−>throwExceptions(true); $front−>setControllerDirectory( ’ / application / controllers ’); 364 Chapitre 9. Introduction au Zend Framework // Utilisation du layout pour l ’affichage Zend_Layout : : startMvc() ; // C’est parti ! $front−>dispatch () ; } catch (Zend_Exception $e) { echo "Erreur dans l ’initialisation du site.<br/>" . "<b>Message: </b> " . $e−>getMessage() ."in".$e−>getFile() . "à la ligne " . $e−>getLine() . "<br />"; } Initialement, on n’y comprend rien, même si les commentaires disent assez clairement le rôle des différentes initialisations effectuées. Regardons dans le détail. Un point important est l’ajout de répertoires dans la liste des chemins d’inclusion de PHP, afin d’accéder d’une part aux classes du Zend Framework, d’autre part aux classes de l’application elles-mêmes. On utilise le loader du ZF pour charger automatiquement les classes sans avoir besoin d’effectuer de nombreux appels à require_once(). Le chargement automatique s’appuie sur une convention largement suivie dans les bibliothèques PHP, consistant à établir une correspondance entre le nom d’une classe et le fichier qui contient sa définition. La classe Zend_Db_Adapter par exemple se trouve dans le fichier Zend/Db/Adapter.php. Comme nous avons placé /usr/local/share/ZF/library dans nos chemins d’inclusion, et que library contient le répertoire Zend qui est la racine de tous les composants Zend, le loader trouve le fichier contenant la classe et la charge automatiquement dès qu’on en a besoin. Plus besoin d’inclusions explicites. Quand l’environnement est initialisé, on peut effectuer le routage de la requête HTTP reçue. Il consiste essentiellement à analyser l’URL de la requête pour déter- miner le contrôleur et l’action demandées, à charger la classe correspondant au contrôleur puis à réaliser l’action. Comme dans notre MVC, un contrôleur spécial, le frontal, se charge du routage. C’est un « singleton » (on ne peut instancier qu’un seul objet de la classe) et sa méthode principale est dispatch() qui distribue les requêtes aux contrôleurs. // Initialisation et exécution d’un contrôleur frontal $front = Zend_Controller_Front :: getInstance() ; $front−>throwExceptions(true); $front−>setControllerDirectory( ’ / application / controllers ’); // Utilisation du layout pour l ’affichage Zend_Layout : : startMvc() ; // C’est parti ! $front−>dispatch () ; 9.1 Mise en route 365 Par défaut, le ZF ne lève pas d’exception, mais sur un site de test comme le nôtre il est préférable, au moins initialement, d’afficher les exceptions avec la commande throwExceptions(true). Il reste des parties du fichier index.php non encore commentées : la lecture du fichier de configuration, la connexion à la base de données, leur placement dans le registre, et l’appel à startMvc(). Elles sont traitées dans les sections qui suivent. 9.1.5 Configuration Toute application a besoin de fichiers de configuration dans lesquels on place des informations dépendantes d’un contexte particulier d’exécution, comme les para- mètresdeconnexionàlabasededonnées. Une solution simple est d’utiliser des tableaux PHP auxquels on peut directement accéder dans un script. Le Zend Framework propose une option plus puissante, basée sur la syntaxe des fichiers INI (comme le php.ini). Cette option présente l’avantage d’un mécanisme d’héritage et de replacement de valeurs très pratique pour configurer des environnements proches les uns des autres. Voici le fichier config.ini, que nous avons choisi de placer dans application (évidemment pas dans www !). Exemple 9.2 zscope/application/config.ini : Le fichier de configuration [ production ] # # Site configuration # app .name = "ZScope" app. base_url = app. display_errors = 0 app. admin_mail = philippe . rigaux@dauphine . fr app. default_timezone = Europe/ Paris app. cookie . lifetime = 3 db. adapter = Pdo_Mysql db. params . host = localhost db. params .dbname = Films db. params. username = adminFilms db . params . pa ssword = mdpAdmin [ staging : production ] app. display_errors = 1 Le contenu du fichier est libre, mais sa structure doit obéir à quelques règles. Tout d’abord, il est décomposé en sections. Ici, nous en avons deux, production et staging, cette dernière définissant l’environnement de test de l’application. La syntaxe [staging: production] indique que staging hérite de 366 Chapitre 9. Introduction au Zend Framework production. En d’autres termes, toutes les valeurs non redéfinies dans staging sont identiques à celles de production. Les autres sont redéfinies. Ainsi, la valeur de display_errors est à 1 pour staging et à 0 pour production : on affiche les erreurs dans un environnement de test, pas dans un environnement de production. Ensuite, les valeurs du fichier de configuration sont organisées hiérarchiquement, en domaines. Nous avons ici deux domaines principaux, app et db, et vous êtes libres de définir vos domaines comme vous l’entendez. Un domaine peut lui-même avoir des sous-domaines, comme db qui dispose d’un sous-domaine params. Le ZF charge un fichier de configuration dans un objet comme suit (ce qui mériterait d’être accompagnée d’un test en cas d’échec) : $config = new Zend_Config_Ini (" / application / config . ini " , " staging"); On indique la section que l’on veut charger. Il suffit de changer staging en production pour passer de l’environnement de test à celui de production. La structure de l’objet reflète la structuration en domaines de la configuration. Il existe donc un objet config->app pour le domaine app, un objet $config->db pour le domaine db, un objet $config->db->params pour le domaine db.params, etc. On accède à une valeur comme à une propriété d’un objet, par exemple $config->app->display_errors pour le choix d’afficher ou non les erreurs. 9.1.6 Connexion à la base de données Le Zend Framework propose une couche d’abstraction pour accéder de manière trans- parente aux bases de données relationnelles, quel que soit le serveur. Une connexion est une instance de Zend_Db_Adapter créée par une « factory » (« usine » instan- ciant des objets en fonction du contexte). Il faut lui passer en paramètres deux informations : 1. le nom de l’adaptateur à utiliser (il existe un adaptateur pour quasiment tous les SGBD) ; 2. les paramètres usuels de connexion. La méthode la plus simple consiste à définir ces paramètres dans le fichier de configuration (voir page 365) dans le domaine db. Une fois le fichier de configuration chargé, il suffit de passer l’objet $config->db àlafactory pour obtenir la connexion // Connexion à la base de données $db = Zend_Db:: factory($config−>db) ; // Cette connexion est à ut i l i s er pour le Modèle Zend_Db_Table :: setDefaultAdapter($db); Cette connexion peut être utilisée de manière classique pour effectuer des requêtes SQL. Elle peut également servir de support pour les composants du Zend Framework qui établissent une correspondance entre le Modèle et la base. L’appel à 9.1 Mise en route 367 setDefaultAdapter() indique que la connexion est utilisée par défaut dans ce cadre. Voir page 379 pour des exemples de recours à cette connexion. Détail potentiellement important : la véritable connexion à la base ne s’effectue qu’avec la première requête effectuée, et c’est à ce moment-là qu’on risque de s’apercevoir que la connexion échoue à cause d’un problème de mot de passe ou autre. Il est possible d’appeler la méthode getConnection() sur l’objet $db pour forcer la connexion et vérifier qu’elle s’exécute correctement. 9.1.7 Le registre Le bootstrap file stocke les objets $config et $db dans le registre de l’application Zend. Il s’agit d’un espace global dans lequel on peut placer des informations utiles partout dans l’application, ce qui évite d’avoir à les passer systématiquement en paramètre. C’est une solution plus propre que l’utilisation des variables globales. Ici, on place l’objet dans une entrée du registre nommée config. Nous verrons un peu plus loin comment accéder à ces entrées. $registry = Zend_Registry :: getInstance () ; $registry−>set ( ’ config ’ , $config) ; 9.1.8 Contrôleurs, actions et vues Regardons ce qui se passe quand on accède simplement à l’URL http://zmax.local. Le frontal détermine tout d’abord que ni le contrôleur, ne l’action ne sont spé- cifiés. Il prend donc ceux par défaut : Index pour le contrôleur et index pour l’action. Le contrôleur est implanté par une classe nommée IndexController dans le répertoire application/controllers, et chaque méthode de cette classe est une action nommée nom Action. Voici le code, très basique, de notre contrôleur par défaut; Exemple 9.3 zscope/application/controllers/IndexController.php : le contrôleur Index. <?php class IndexController extends Zend_Controller_Action { /∗∗ ∗ L’ action par défaut . Elle affiche juste la page ∗ d’accueil. ∗ / function indexAction() { $this−>view−>titre_page = "Page d’accueil"; } /∗∗ . d’héritage et de replacement de valeurs très pratique pour configurer des environnements proches les uns des autres. Voici le fichier config.ini, que nous avons choisi de placer dans application (évidemment. défaut : Index pour le contrôleur et index pour l’action. Le contrôleur est implanté par une classe nommée IndexController dans le répertoire application/controllers, et chaque méthode de cette classe. charger. Il suffit de changer staging en production pour passer de l’environnement de test à celui de production. La structure de l’objet reflète la structuration en domaines de la configuration.