6.3 Structure d’une application MVC : la vue 263 <!−− Le formulaire pour saisir la requête −−> <center> <form method=’post ’ action =’?ctrl=saisie&action=recherche ’> <b>Titre ou partie du titre</b> <input type=’text ’ name=" titre " value="" size =’30’ maxlength =’30’/> <input type=’submit ’ name="submit" value="Rechercher" /> </form> </ center> Rappelons que notre « layout » comprend deux références d’entités : titre_page et contenu (voir ce qui précède). Le but de chaque action (au moins en ce qui concerne la présentation du résultat) est de créer une valeur pour ces deux entités. Voici l’action form_recherche. function form_recherche () { /∗ Définition du titre ∗ / $this−>vue−>titre_page = "Recherche des films " ; /∗∗ ∗ On charge le template "saisie_recherche" ∗ dans l ’ entité "contenu" ∗ / $this−>vue−>setFile("contenu" , "saisie_form_recherche . tpl"); /∗ Il n’y a plus qu’à afficher . ∗/ echo $this−>vue−>render ("page"); } C’est une page statique, qui se contente de combiner deux templates en plaçant le contenu du fichier saisie_form_recherche.tpl dans l’entité contenu du layout. La seconde action est un peu plus longue (forcément). Voyons d’abord le template : Exemple 6.12 Le template saisie_recherche.tpl montrant le résultat de la recherche <p> <b>Voici le résultat de votre recherche . </b> Vous pouvez maintenant utiliser le lien "mise à jour " pour accéder à un formulaire de modification des films . </p> <center> < table border =’4’ cellspacing=’5’> < tr class="header"> <th>Titre</th><th>Année</ th><th>Action</ th> </ tr> <!−− Le bloc pour le template affichant une ligne −−> <!−− BEGIN l i g n e −−> 264 Chapitre 6. Architecture du site: le pattern MVC < tr class =’{classe_css } ’> <td>{titre_film }</td><td>{ annee }</ td> <td><ahref="? ctrl=saisie& action=form_modifier& id={ id_film }"> Mise à jour</a> </td> </ tr> <!−− END ligne −−> </ table> </ center> Il s’agit de deux templates imbriqués. Le second, marqué par les commentaires BEGIN et END, correspond à chaque ligne du tableau montrant les films. À l’inté- rieur de ce template imbriqué on trouve les références aux entités classe_css, titre_film, id_film,etannee. Le code de l’action est donné ci-dessous : les commentaires indiquent le rôle de chaque partie. function recherche () { // Définition du titre $this−>vue−>titre_page = "Résultat de la recherche" ; // On charge les templates nécessaires $this−>vue−>setFile("texte" , "saisie_recherche . tpl"); // On extrait le bloc imbriqué "ligne", et on le remplace par // la référence à une entité "lignes" $this−>vue−>setBlock ("texte" , "ligne" , "lignes"); // Le titre a été saisi ? On effectue la recherche if ( i s S e t ($_POST[ ’ t i t r e ’ ]) ) { $titre = htmlEntities($_POST[ ’ titre ’]) ; } else { // Il faudrait sans doute protester? $titre = ""; } // Exécution de la requête $ r e q uet e = "SELECT ∗ FROM Film WHERE titre LIKE ’%$titre%’ " ; $resultat = $this−>bd−>execRequete( $requete ) ; $compteur = 1; while ($film = $this−>bd−>objetSuivant ($resultat)) { if ($compteur++ % 2 == 0) $classe = "even" ; else $classe = "odd" ; // Affectation des entités de la ligne $this−>vue−>classe_css = $classe ; $this−>vue−>titre_film = $film−>titre ; $this−>vue−>id_film = $film−>id ; 6.3 Structure d’une application MVC : la vue 265 $this−>vue−>annee = $film−>annee ; // On effectue la substitution dans "ligne", en concaténant // le résultat dans l ’entité "lignes" $this−>vue−>append ( " lignes " , " ligne ") ; } // On a le formulaire et le tableau : on parse et on place // le résultat dans l ’entité ’contenu ’ $this−>vue−>assign ("contenu" , " texte "); /∗ Il n’y a plus qu’à afficher. ∗ / echo $this−>vue−>render ("page"); } Notez que l’action attend en paramètre une variable titre transmise en post.En principe ce paramètre vient du formulaire. Une action devrait toujours vérifier que les paramètres attendus sont bien là, et filtrer leur valeur (en supprimant par exemple les balises HTML que des personnes malicieuses pourraient y injecter). C’est ce que fait la fonction htmlEntities(), en remplaçant les caractères réservés HTML par des appels d’entités. Rappelez-vous toujours qu’un script PHP peut être déclenché par n’importe qui, et pas toujours avec de bonnes intentions. Ces actions sont du « pur » PHP, sans aucune trace de HTML. Si on conçoit les choses avec soin, on peut structurer ainsi une application MVC en fragments de code, chacun d’une taille raisonnable, avec une grande clarté dans l’organisation de toutes les parties de l’application. Avant d’étudier la dernière partie du MVC, le modèle, nous allons comme promis revenir un moment sur les avantages et inconvénients du système de templates pour gérer le composant Vue. 6.3.5 Discussion Les templates offrent un bon exemple de la séparation complète de la « logique » de l’application, codée en PHP, et de la présentation, codée en HTML. Une des forces de ce genre de système est que toute la mise en forme HTML est écrite une seule fois, puis reprise et manipulée grâce aux fonctions PHP. On évite donc, pour les modifications du site, l’écueil qui consisterait à dupliquer une mise en forme autant de fois qu’il y a de pages dans le site. C’est ce que doit satisfaire tout gestionnaire de contenu HTML digne de ce nom en proposant une notion de « style » ou de « modèle » dont la mise à jour est répercutée sur toutes les pages reposant sur ce style ou ce modèle. Un problème délicat reste la nécessité de produire un nombre très important de templates si on veut gérer la totalité du site de cette manière et interdire la production de tout code HTML avec PHP. Cette multiplication de « petits » modèles (pour les tableaux, les lignes de tableaux, les formulaires et tous leurs types de champs, etc.) peut finir par être très lourde à gérer. Imaginez par exemple ce que peut être la production avec des templates d’un formulaire comme ceux que nous pouvons obtenir avec la classe Formulaire, comprenant une imbrication de tableaux, de champs de saisie et de valeurs par défauts fournies en PHP. 266 Chapitre 6. Architecture du site: le pattern MVC Un bon compromis est d’utiliser des modèles de page créés avec un générateur de documents HTML, pour la description du graphisme du style. Cela correspond grosso modo à l’en-tête, au pied de page et aux tableaux HTML qui définissent l’em- placement des différentes parties d’une page. On place dans ces modèles des entités qui définissent les composants instanciés par le script PHP : tableaux, formulaires, menus dynamiques, etc. Ensuite, dans le cadre de la programmation PHP, on prend ces modèles comme templates, ce qui rend le code indépendant du graphisme, et on utilise, pour produire le reste des éléments HTML, plus neutres du point de vue de la présentation, les utilitaires produisant des objets HTML complexes comme Tableau ou Formulaire. Le code PHP produit alors ponctuellement des composants de la page HTML, mais dans un cadre bien délimité et avec des utilitaires qui simplifient beaucoup cette tâche. L’utilisation des feuilles de style CSS permet de gérer quand même la présentation de ces éléments HTML. Il suffit pour cela de prévoir l’ajout d’une classe CSS dans les balises HTML produites. Cette solution limite le nombre de templates nécessaires, tout en préservant un code très lisible. On peut également s’intéresser à des systèmes de templates plus évolués que celui présenté ici. Il en existe beaucoup (trop ). Attention cependant : le choix d’un système de templates a un impact sur tout le code du site, et il n’est pas du tout facile de faire marche arrière si on s’aperçoit qu’on a fait fausse route. Posez-vous les quelques questions suivantes avant de faire un choix : • Le système préserve-t-il la simplicité de production du code HTML, ou faut-il commencer à introduire des syntaxes compliquées dans les templates pour décrire des boucles, des éléments de formulaire, etc. La méthode consistant à décrire des blocs est un premier pas vers l’introduction de structures de programmation (boucles, tests) dans les modèles, et il est tentant d’aller au-delà. Si la personne responsable du code HTML doit se transformer en programmeur, on perd cependant l’idée de départ • Le système est-il répandu, bien documenté, soutenu par une collectivité active et nombreuse de programmeurs ? Est-il, au moins en partie, compatible avec les systèmes classiques ? • Quelles sont ses performances ? Est-il doté d’un système de cache qui évite d’effectuer systématiquement les opérations coûteuses de substitution et de copies de chaînes de caractères ? Gardez en vue qu’un bon système de templates doit avant tout faciliter la répar- tition des tâches et rester simple et efficace. Il paraît peu raisonnable de se lancer dans des solutions sans doute astucieuses mais complexes et non normalisées. Si vraiment la séparation du contenu et de la présentation est très importante pour vous, par exemple parce que vous souhaitez produire plusieurs formats différents (HTML, WML, PDF, etc.) à partir d’un même contenu, pourquoi ne pas étudier les outils basés sur XML comme le langage de transformation XSLT, introduit dans le chapitre 8 ? Ces langages sont normalisés par le W3C, on bénéficie donc en les adoptant des très nombreux outils et environnements de développement qui leur sont consacrés. 6.4 Structure d’une application MVC : le modèle 267 Nous verrons également dans le chapitre 9 une approche pour gérer la vue, celle du Zend Framework, assez différente des systèmes de templates. Elle a le mérite d’utiliser directement PHP pour la mise en forme, ce qui évite d’avoir à inventer un nouveau pseudo-langage de programmation. En contrepartie la saisie est lourde et le code obtenu peu plaisant à lire. Le système idéal, simple, léger, lisible et bien intégré à PHP, reste à définir. En résumé, le style d’imbrication de PHP et de HTML fait partie des questions importantes à soulever avant le début du développement d’un site. La réponse varie en fonction de la taille du développement et de l’équipe chargée de la réalisation, des outils disponibles, des compétences de chacun, des contraintes (le site doit-il évoluer fréquemment ? Doit-il devenir multilingue à terme, certaines fonctionnalités sont-elles communes à d’autre sites ?), etc. J’espère que les différentes techniques présentées dans ce livre vous aideront à faire vos choix en connaissance de cause. 6.4 STRUCTURE D’UNE APPLICATION MVC : LE MODÈLE Il nous reste à voir le troisième composant de l’architecture MVC : le modèle. Le modèle est constitué de l’ensemble des fonctionnalités relevant du traitement (au sens large) des données manipulées par l’application. Cette notion de traitement exclut la présentation qui, nous l’avons vu, est prise en charge par la vue. Tout ce qui concerne la gestion des interactions avec l’utilisateur ainsi que le workflow (séquence des opérations) relève du contrôleur. Par élimination, tout le reste peut être imputé au modèle. Il faut souligner qu’on y gagne de ne pas du tout se soucier, en réalisant le modèle, du contexte dans lequel il sera utilisé. Un modèle bien conçu et implanté peut être intégré à une application web mais doit pouvoir être réutilisé dans une application client/serveur, ou un traitement batch. On peut le réaliser de manière standard, sous forme de fonctions ou de classes orientées-objet, sans se soucier de HTML. Il n’y aurait pas grand-chose de plus à en dire si, très souvent, le modèle n’était pas également le composant chargé d’assurer la persistance des données, autrement dit leur survie indépendamment du fonctionnement de l’application. 6.4.1 Modèle et base de données : la classe TableBD Dans des applications web dynamiques, le modèle est aussi une couche d’échange entre l’application et la base de données. Cette couche peut simplement consister en requêtes SQL de recherche et de mise à jour. Elle peut être un peu plus sophistiquée et factoriser les fonctions assurant les tâches routinières : recherche par clé, insertion, mise à jour, etc. À l’extrême, on peut mettre en œuvre un mapping objet-relationnel (Objet-Relational Mapping, ORM en anglais) qui propose une vue de la base de données reposant sur des classes orientées-objet. Ces classes masquent le système relationnel sous-jacent, ainsi que les requêtes SQL. Comme d’habitude, essayons d’être simples et concret : dans ce qui suit je propose une couche Modèle un peu plus élaborée que la communication par SQL, et je montre comment l’exploiter dans notre site pour des recherches (pas trop sophis- tiquées) et des mises à jour. Le chapitre 9 montre avec le Zend Framework le degré d’abstraction que l’on peut obtenir avec une couche ORM. . nécessité de produire un nombre très important de templates si on veut gérer la totalité du site de cette manière et interdire la production de tout code HTML avec PHP. Cette multiplication de « petits. fonction de la taille du développement et de l’équipe chargée de la réalisation, des outils disponibles, des compétences de chacun, des contraintes (le site doit-il évoluer fréquemment ? Doit-il devenir. code PHP produit alors ponctuellement des composants de la page HTML, mais dans un cadre bien délimité et avec des utilitaires qui simplifient beaucoup cette tâche. L’utilisation des feuilles de