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..
Trang 1< !−− Le f o r m u l a i r e p o u r s a i s i r l a r e q u ê t e −−>
< c e n t e r >
<form method = ’ p o s t ’ a c t i o n = ’ ? c t r l = s a i s i e& ; a c t i o n = r e c h e r c h e ’ >
<b> T i t r e ou p a r t i e du t i t r e < / b>
< i n p u t t y p e = ’ t e x t ’ name= " t i t r e " v a l u e = " " s i z e = ’ 3 0 ’ m a x l e n g t h
= ’ 3 0 ’ / >
< i n p u t t y p e = ’ s u b m i t ’ name= " s u b m i t " v a l u e = " R e c h e r c h e r " / >
< / form>
< / c e n t e r >
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
f u n c t i o n f o r m _ r e c h e r c h e ( )
{
/ ∗ D é f i n i t i o n du t i t r e ∗ /
$ t h i s−>vue−>t i t r e _ p a g e = " Recherche de s f i l m s " ;
/ ∗ ∗
∗ On c h a r g e l e t e m p l a t e " s a i s i e _ r e c h e r c h e "
∗ d a n s l ’ e n t i t é " c o n t e n u "
∗ /
$ t h i s−>vue−> s e t F i l e ( " contenu " , " s a i s i e _ f o r m _ r e c h e r c h e t p l " ) ; / ∗ I l n ’ y a p l u s qu ’ à a f f i c h e r ∗ /
echo $ t h i s−>vue−>r e n d e r ( " page " ) ;
}
C’est une page statique, qui se contente de combiner deux templates en plaçant le contenu du fichiersaisie_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> V o i c i l e r é s u l t a t de v o t r e r e c h e r c h e < / b> Vous
p o u v e z m a i n t e n a n t u t i l i s e r l e l i e n " m i s e à j o u r "
p o u r a c c é d e r à un f o r m u l a i r e de m o d i f i c a t i o n d e s f i l m s
< / p>
< c e n t e r >
< t a b l e b o r d e r = ’ 4 ’ c e l l s p a c i n g = ’ 5 ’ >
< t r c l a s s = " h e a d e r " >
< t h > T i t r e < / t h >< t h >Année< / t h >< t h > A c t i o n < / t h >
< / t r >
< !−− Le b l o c p o u r l e t e m p l a t e a f f i c h a n t une l i g n e −−>
< !−− BEGIN l i g n e −−>
Trang 2264 Chapitre 6 Architecture du site : le pattern MVC
< t r c l a s s = ’ { c l a s s e _ c s s } ’ >
< t d > { t i t r e _ f i l m } < / t d >< t d > { annee } < / t d >
< t d ><a h r e f = " ? c t r l = s a i s i e& ; a c t i o n = f o r m _ m o d i f i e r& ; i d = {
i d _ f i l m } " >
Mise à j o u r < / a>
< / t d >
< / t r >
< !−− END l i g n e −−>
< / t a b l e >
< / c e n t e r >
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, et annee Le code de l’action est donné ci-dessous : les commentaires indiquent le rôle de chaque partie
f u n c t i o n r e c h e r c h e ( )
{
/ / D é f i n i t i o n du t i t r e
$ t h i s−>vue−>t i t r e _ p a g e = " R é s u l t a t de l a r e c h e r c h e " ;
/ / On c h a r g e l e s t e m p l a t e s n é c e s s a i r e s
$ t h i s−>vue−> s e t F i l e ( " t e x t e " , " s a i s i e _ r e c h e r c h e t p l " ) ;
/ / On e x t r a i t l e b l o c i m b r i q u é " l i g n e " , e t on l e r e m p l a c e p a r / / l a r é f é r e n c e à u n e e n t i t é " l i g n e s "
$ t h i s−>vue−>s e t B l o c k ( " t e x t e " , " l i g n e " , " l i g n e s " ) ;
/ / Le t i t r e a é t é s a i s i ? On e f f e c t u e l a r e c h e r c h e
i f ( i s S e t ( $_POST [ ’ t i t r e ’ ] ) ) {
$ t i t r e = h t m l E n t i t i e s ( $_POST [ ’ t i t r e ’ ] ) ;
}
e l s e {
/ / I l f a u d r a i t s a n s d o u t e p r o t e s t e r ?
$ t i t r e = " " ;
}
/ / E x é c u t i o n d e l a r e q u ê t e
$ r e q u e t e = " SELECT ∗ FROM Film WHERE t i t r e LIKE ’% $ t i t r e %’ " ;
$ r e s u l t a t = $ t h i s−>bd−>execRequete ( $ r e q u e t e ) ;
$ c o m p t e u r = 1 ;
w h i l e ( $ f i l m = $ t h i s−>bd−>o b j e t S u i v a n t ( $ r e s u l t a t ) ) {
i f ( $ c o m p t e u r ++ % 2 == 0 ) $ c l a s s e = " even " ; e l s e $ c l a s s e =
" odd " ;
/ / A f f e c t a t i o n d e s e n t i t é s d e l a l i g n e
$ t h i s−>vue−> c l a s s e _ c s s = $ c l a s s e ;
$ t h i s−>vue−> t i t r e _ f i l m = $film −> t i t r e ;
$ t h i s−>vue−>i d _ f i l m = $film −>i d ;
Trang 3$ t h i s−>vue−>annee = $film −>annee ;
/ / On e f f e c t u e l a s u b s t i t u t i o n d a n s " l i g n e " , e n c o n c a t é n a n t / / l e r é s u l t a t d a n s l ’ e n t i t é " l i g n e s "
$ t h i s−>vue−>append ( " l i g n e s " , " l i g n e " ) ;
}
/ / On a l e f o r m u l a i r e e t l e t a b l e a u : on p a r s e e t on p l a c e / / l e r é s u l t a t d a n s l ’ e n t i t é ’ c o n t e n u ’
$ t h i s−>vue−>a s s i g n ( " contenu " , " t e x t e " ) ;
/ ∗ I l n ’ y a p l u s qu ’ à a f f i c h e r ∗ /
echo $ t h i s−>vue−>r e n d e r ( " 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
Trang 4266 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 cỏ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
Trang 5Nous 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 classeTableBD
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