stahe-php-mvc.pdf

5/26/2018 stahe-php-mvc.pdf

1/58

Mthodologie de dveloppement

MVC d'une application PHP

par Serge Tah(Cours et articles)

Date de publication : Janvier 2004

Dernire mise jour : 2 aot 2008

Ce document propose une mthode de dveloppement d'applications Web/PHP respectant

l'architecture MVC(Modle - Vue - Contrleur).
http://dico.developpez.com/html/3020-Conception-MVC-Model-View-Controller.phphttp://tahe.developpez.com/mailto:[email protected]://www.developpez.com/


2/58

Mthodologie de dveloppement MVC d'une application PHP par Serge Tah(Cours et articles)

- 2 -Copyright 2004 - Serge Tah. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes,documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 Ede dommages et intrts.

http://tahe.developpez.com/web/php/mvc/

I - Utiliser l'architecture MVC dans les applications Web/PHP...................................................................................4II - Une dmarche de dveloppement MVC en Web/PHP.........................................................................................6III - Un contrleur gnrique.....................................................................................................................................10

III-A - Introduction................................................................................................................................................ 10III-B - Le fichier de configuration de l'application................................................................................................ 11III-C - Les bibliothques inclure dans le contrleur..........................................................................................11

III-D - La gestion des sessions............................................................................................................................12III-E - L'excution des actions............................................................................................................................. 12III-F - L'enchanement des actions...................................................................................................................... 14III-G - L'envoi de la rponse au client.................................................................................................................15III-H - Dbogage...................................................................................... ............................................................ 16III-I - Conclusion...................................................................................................................................................17

IV - Une application d'illustration.............................................................................................................................. 18IV-A - Le problme.............................................................................................................................................. 18IV-B - La base de donnes................................................................................................................................. 18IV-C - L'architecture MVC de l'application...........................................................................................................19IV-D - La classe d'accs aux donnes................................................................................................................19IV-E - La classe de calcul de l'impt...................................................................................................................23

IV-F - Le fonctionnement de l'application............................................................................................................24IV-G - Retour sur l'architecture MVC de l'application..........................................................................................27IV-H - Lecontrleur de l'application....................................................................................................................27IV-I - Les actions de l'application web.................................................................................................................29IV-J - Les tats de l'application web................................................................................................................... 29IV-K - Le fichier config.php de configuration de l'application web.......................................................................30IV-L - Les actions de l'application web................................................................................................................31

IV-L-1- Fonctionnement gnral des scripts d'action....................................................................................31IV-L-2 - L'action get:init.................................................................................................................................. 31IV-L-3 - L'action post:calculerimpot................................................................................................................32IV-L-4 - L'action get:effacerformulaire............................................................................................................ 33IV-L-5 - L'action get:retourformulaire..............................................................................................................33

IV-M - L'enchanement d'actions invalide............................................................................................................34IV-N - Les vues de l'application.......................................................................................................................... 35

IV-N-1- Affichage de la vue finale.................................................................................................................35IV-N-2- Modle de la rponse...................................................................................................................... 36IV-N-3 - La vue lmentaire v-bandeau.php..................................................................................................37IV-N-4 - La vue lmentaire v-formulaire.php................................................................................................38IV-N-5 - La vue lmentaire v-erreurs.php.................................................................................................... 38IV-N-6 - La feuille de style............................................................................................................................. 39

IV-O - Les gnrateurs de vues..........................................................................................................................40IV-O-1- Rle d'un gnrateur de vue........................................................................................................... 40IV-O-2- Le gnrateur de vue associe l'tat [e-formulaire]......................................................................41IV-O-3- La vue associe l'tat [e-erreurs]................................................................................................. 42IV-O-4- Affichage de la vue finale................................................................................................................ 43

IV-P - Modifier le modle de rponse................................................................................................................. 43IV-P-1- Le nouveau modle..........................................................................................................................43IV-P-2- Les diffrentes pages rponse.........................................................................................................44IV-P-3- Les vues lmentaires......................................................................................................................47IV-P-4- La feuille de style............................................................................................................................. 49IV-P-5- Le nouveau fichier de configuration................................................................................................. 49IV-P-6- Le gnrateur de vue associ l'tat [e-formulaire]........................................................................50IV-P-7- Le gnrateur devue associ l'tat [e-erreurs]............................................................................ 51

V - Conclusion...........................................................................................................................................................52VI - ANNEXE - PEAR DB.........................................................................................................................................53

VI-A - PEAR DB: a unifiedAPI for accessing SQL-databases........................................................................... 53VI-A-1 - DSN.................................................................................................................................................. 53

VI-A-2 - Connect.............................................................................................................................................54VI-A-3 - Query................................................................................................................................................ 54VI-A-4 - Fetch.................................................................................................................................................55
http://tahe.developpez.com/web/php/mvc/http://tahe.developpez.com/web/php/mvc/http://tahe.developpez.com/web/php/mvc/http://tahe.developpez.com/mailto:[email protected]://www.developpez.com/


3/58




VI-A-4-a - Select the format of the fetched row....................................................................................... 55VI-A-4-b - Set the format of the fetched row............................................................................................56VI-A-4-c - Fetch rows by number............................................................................................................. 56VI-A-4-d - Freeing the result set...............................................................................................................57VI-A-4-e - Quick data retrieving................................................................................................................57VI-A-4-f - Getting more information from query results............................................................................ 58


4/58




I - Utiliser l'architecture MVC dans les applications Web/PHP

Le modle MVC(Modle-Vue-Contrleur) cherche sparer nettement les couches prsentation, traitement etaccs aux donnes. Une application web respectant ce modle sera architecture de la faon suivante :

Le traitement d'une demande d'un client se droule selon les tapes suivantes :1 Le client fait une demande au contrleur. Ce contrleur voit passer toutes les demandes des clients. C'est la

porte d'entre de l'application. C'est le C de MVC.2 Le contrleur traite cette demande. Pour ce faire, il peut avoir besoin de l'aide de la couche mtier, ce qu'on

appelle le modle M dans la structure MVC.3 Le contrleur reoit une rponse de la couche mtier. La demande du client a t traite. Celle-ci peut

appeler plusieurs rponses possibles. Un exemple classique est# Une page d'erreurs si la demande n'a pu tre traite correctement# Une page de confirmation sinon

4 Le contrleur choisit la rponse (= vue) envoyer au client. Celle-ci est le plus souvent une page contenantdes lments dynamiques. Le contrleur fournit ceux-ci la vue.

5 La vue est envoye au client. C'est le V de MVC.

Une telle architecture est souvent appele "architecture 3-tier" ou 3 niveaux.

L'interface utilisateurest souvent un navigateur web mais cela pourrait tre galement une application autonomequi via le rseau enverrait des requtes HTTP au service web et mettrait en forme les rsultats que celui-ci lui envoie.La logique applicativeest constitue des scripts traitant les demandes de l'utilisateur, des classes mtier et d'accsaux donnes. La source de donnesest souvent une base de donnes mais cela peut tre aussi de simples fichiersplats, un annuaire LDAP, un service web distant,... Le dveloppeur a intrt maintenir une grande indpendanceentre ces trois entits afin que si l'une d'elles change, les deux autres n'aient pas changer ou peu.

L'architecture MVC est bien adapte des applications web crites avec des langages orients objet. Le langagePHP (4.x) n'est pas orient objet. On peut nanmoins faire un effort de structuration du code et de l'architecture del'application afin de se rapprocher du modle MVC :

On mettra la logique mtier de l'application dans des modules spars des modules chargs de contrler ledialogue demande-rponse. L'architecture MVC devient la suivante :
http://tahe.developpez.com/web/php/mvc/http://dico.developpez.com/html/3020-Conception-MVC-Model-View-Controller.phphttp://tahe.developpez.com/web/php/mvc/http://tahe.developpez.com/mailto:[email protected]://www.developpez.com/


5/58




M=modle les classes mtier, les classes d'accs auxdonnes et la base de donnes

V=vues les pages PHPC=contrleur le script PHP de traitement des requtes

clientes, les scripts PHP [Action] detraitement des actions.

Dans le bloc [Logique Applicative], on pourra distinguer : Le programme principal ou contrleur [main.php], qui est la porte d'entre de l'application.

Le bloc [Actions], ensemble de scripts PHP chargs d'excuter les actions demandes par l'utilisateur.

Le bloc [Classes mtier] qui regroupe les modules PHP ncessaires la logique de l'application. Ils sontindpendants du client. Par exemple, la fonction permettant de calculer un impt partir de certainesinformations qui lui sont fournies en paramtres, n'a pas se soucier de la faon dont ont t acquises celles-ci.

Le bloc [Classes d'accs aux donnes] qui regroupe les modules PHP qui obtiennent les donnesncessaires au contrleur, souvent des donnes persistantes (BD, fichiers, ...)

Les gnrateurs [pagex.php] des vues envoyes comme rponse au client.

Dans les cas les plus simples, la logique applicative est souvent rduite deux

modules :

Le module [contrle] assurant le dialogue client-serveur : traitement de la requte, gnration des diversesrponses

Le module [mtier] qui reoit du module [contrle] des donnes traiter et lui fournit en retour des rsultats.Ce module [mtier] gre alors lui-mme l'accs aux donnes persistantes.
http://tahe.developpez.com/web/php/mvc/http://tahe.developpez.com/web/php/mvc/http://tahe.developpez.com/mailto:[email protected]://www.developpez.com/


6/58




II - Une dmarche de dveloppement MVC en Web/PHP

Nous proposons ici une dmarche pour le dveloppement d'applications web/php respectant l'architecture MVC. Ellen'est l que pour ouvrir des pistes. Le lecteur l'adaptera ses gots et besoins.

On commencera par dfinir toutes les vues de l'application. Celles-ci sont les pages web prsentes l'utilisateur. On se placera du point de vue de celui-ci pour dessiner les vues. On distingue trois types devues :

Leformulaire de saisiequi vise obtenir des informations de l'utilisateur. Celui-ci dispose en gnral d'unbouton pour envoyer au serveur les informations saisies.

La page de rponsequi ne sert qu' donner de l'information l'utilisateur. Celle-ci dispose souvent d'un oude plusieurs liens permettant l'utilisateur de poursuivre l'application avec une autre page.

lapage mixte: le contrleur a envoy au client une page contenant des informations qu'il a gnres. Cette mmepage va servir au client pour fournir au contrleur de nouvelles informations provenant de l'utilisateur.

Chaque vue donnera naissance une page PHP. Pour chacune de celles-ci :

On dessinera l'aspect de la page

On dterminera quelles sont les parties dynamiques de celle-ci :

Les informations destination de l'utilisateur qui devront tre fournies par le contrleur en paramtres lavue PHP. Une solution simple est la suivante :

Le contrleur met dans un dictionnaire $dReponseles informations qu'il veut fournir une vue V

Le contrleur fait afficher la vue V. Si celle-ci correspond au fichier source V.php, cet affichage est obtenusimplement par l'instruction includeV.php.

L'inclusion prcdente est une inclusion de code dans le contrleur. Le dictionnaire $dReponserenseignpar celui-ci est accessible directement par le code de V.php.

Les donnes de saisie qui devront tre transmises au programme principal pour traitement. Celles-ci devrontfaire partie d'un formulaire HTML (balise ).

On pourra schmatiser les E/S de chaque vue

Les entres sont les donnes que devra fournir le contrleur la page PHP

Les sorties sont les donnes que devra fournir la page PHP au contrleur de l'aplication. Elles font partie d'unformulaire HTML et le contrleur les rcuprera par une opration du type $_GET["param"](mthode GET)ou$_POST ["param"](mthode POST).

Frquemment, la page finale envoye au client n'est pas une vue mais une composition de vues. Par

exemple, la page envoye un utilisateur peut avoir la forme suivante :


7/58




La zone 1 peut tre un bandeau de titre, la zone 2 un bandeau de menu, la zone 3 une zone de contenu. En PHPcette composition peut tre obtenue par le code HTML/PHP suivant :

On peut rendre ce code dynamique en crivant :

Cette composition de vues peut tre le format unique de la rponse faite l'utilisateur. Dans ce cas, chaque rponseau client devra fixer les trois URL charger dans les trois zones avant de faire afficher la page rponse. On peutgnraliser cet exemple en imaginant qu'il y ait plusieurs modles possibles pour la page de rponse. La rponse

au client devra donc :

Fixer le modle utiliser

Fixer les lments (vues lmentaires) inclure dans celui-ci

Demander l'affichage du modle

On crira le code PHP/HTML de chaque modle de rponse. Son code est gnralement simple. Celui de l'exempleci-desssus pourrait tre :

On utilisera chaque fois que c'est possible une feuille de style afin de pouvoir changer le "look" de la rponse sansavoir modifier le code PHP/HTML.

On crira le code PHP/HTML de chaque vue lmentaire, lment de la page envoye en rponse au client.Il aura le plus souvent la forme suivante :


8/58




...

// on cherchera ici minimiser le code php

On notera qu'une vue lmentaire s'intgre dans un modle qui les assemble pour en faire une page HTML. Le codeHTML de la vue lmentaire vient s'insrer dans le code du modle prsent l'tape prcdente. Le plus souvent,le code du modle intgre dj les balises , , . Il est donc peu frquent de trouver ces balisesdans une vue lmentaire.

On peut procder aux tests des diffrents modles de rponse et vues lmentaires

Chaque modle de rponse est test. Si un modle s'appelle modele1.php, on demandera avec unnavigateur l'URL http://localhost/chemin/modele1.phpLe modle attend des valeurs du contrleur. Ici onl'appelle directement et non via le contrleur. Le modle ne recevra pas les paramtres attendus. Afin queles tests soient nanmoins possibles on initialisera soi-mme, avec des constantes, les paramtres attendusdans la page PHP du modle.

Chaque modle est test ainsi que toutes les vues lmentaires. C'est aussi le moment d'laborer lespremiers lments des feuilles de style utilises.

On crit ensuite la logique applicative de l'application :

Le contrleur ou programme principal gre en gnral plusieurs actions. Il faut que dans les requtes qui luiparviennent l'action accomplir soit dfinie. Cela peut se faire au moyen d'un paramtre de la requte quenous appellerons ici action:

Si la requte provient d'un formulaire (), ce paramtre peut tre un paramtre cach du formulaire :...

Si la requte provient d'un lien, on peut paramtrer celui-ci :

lien

Le contrleur peut commencer par lire la valeur de ce paramtre puis dlguer le traitement de la requte unmodule charg de traiter ce type de requte. Nous nous plaons ici dans le cas ou tout est contrl par un uniquescript appel main.php. Si l'application doit traiter des actions action1, action2, ..., actionxon peut crer au seindu contrleur une fonction par action. S'il y a beaucoup d'actions, on peut arriver un contrleur "dinosaure". Onpeut aussi crer des scripts action1.php, action2.php, ...,actionx.phpchargs de traiter chacune des actions. Lecontrleur devant traiter l'acton actionx se contentera de charger le code du script correspondant par une instructiondu genre include "actionx.php". L'avantage de cette mthode est qu'on travaille en-dehors du code du contrleur.Chaque personne de l'quipe de dveloppement peut ainsi travailler sur le script de traitement d'une action actionx defaon relativement indpendante. L'inclusion du code du script actionx.phpdans le code du contrleur au momentde l'excution a galement l'avantage d'allger le code charg en mmoire. Seul le code de traitement de l'action encours est charg. Cette inclusion de code fait que des variables du contrleur peuvent entrer en collision avec cellesdu script de l'action. Nous verrons que nous pouvons faire en sorte de limiter les variables du contrleur quelquesvariables bien dfinies qu'il faudra alors viter d'utiliser dans les scripts.

On cherchera systmatiquement isoler le code mtier ou le code d'accs aux donnes persistantes dansdes modules distincts. Le contrleur est une sorte de chef d'quipe qui reoit des demandes de ses clients(clients web) et qui les fait excuter par les personnes les plus appropries (les modules mtier). Lors del'criture du contrleur, on dterminera l'interface des modules mtier crire. Cela si ces modules mtiersont construire. S'ils existent dj, alors le contrleur s'adaptera l'interface de ces modules existants.

On crira le squelette des modules mtier ncessaires au contrleur. Par exemple, si celui-ci utilise unmodule getCodesrendant un tableau de chanes de caractres, on peut se contenter dans un premier tempsd'crire :

functiongetCodes(){

returnarray("code1","code2","code3");


9/58




}

On peut alors passer aux tests du contrleur et des scripts PHP associs :

Le contrleur, les scripts d'actions, les modles, les vues, les ressources ncessaires l'application

(images,...) sont placs dans le dossier DCassoci au contexte Cde l'application.

Ceci fait, l'application est teste et les premires erreurs corriges. Si main.php est le contrleur et Cle contexte de l'application, on demandera l'URL http://localhost/C/main.php. A la fin de cette phase,l'architecture de l'application est oprationnelle. Cette phase de test peut tre dlicate sachant qu'on n'apeu d'outils de dbogage si on n'utilise pas des environnements de dveloppement volus et en gnralpayants. On pourra s'aider d'instructions echo "message"qui crivent dans le flux HTML envoy au client etqui apparaissent donc dans la page web affiche par le navigateur.

On crit enfin les classes mtier dont a besoin le contrleur. On a l en gnral le dveloppement classiqued'une classe PHP, dveloppement le plus souvent indpendant de toute application web. Elle sera toutd'abord teste en dehors de cet environnement, avec une application console par exemple. Lorsqu'uneclasse mtier a t crite, on l'intgre dans l'architecture de dploiement de l'application web et on teste sacorrecte intgration. On procdera ainsi pour chaque classe mtier.


10/58




III - Un contrleur gnrique

III-A - Introduction

Dans la mthode prcdente, il tait entendu que nous avions crire le contrleur appel main.php. Avec un peud'exprience, on ralise que ce contrleur fait souvent les mmes choses et il est alors tentant d'crire un contrleurgnrique utilisable dans la plupart des applications web. Le code de ce contrleur pourrait tre le suivant :


11/58




}else{

// pas de session

session_destroy();

}

// on prsente la rponse

include$dConfig['vuesReponse'][$dReponse['vuereponse']]['url'];

// fin du script

exit(0);

}//finsession

//--------------------------------------------------------------------

functionenchainementOK(&$dConfig,&$dSession,$sAction){

// vrifie si l'action courante est autorise vis vis de l'tat prcdent

$etat=$dSession['etat']['principal'];

if(!isset($etat)) $etat='sansetat';

// vrification action

$actionsautorisees=$dConfig['etats'][$etat]['actionsautorisees'];

$autorise=!isset($actionsautorisees) ||in_array($sAction,$actionsautorisees);

return$autorise;

}

//--------------------------------------------------------------------

functiondump($dInfos){

// affiche un dictionnaire d'informations

while(list($cl,$valeur)=each($dInfos)){

echo"[$cl,$valeur]
\n";

}//while

}//suivi

//--------------------------------------------------------------------

functiontrace($msg){

echo$msg."
\n";

}//suivi

?>

III-B - Le fichier de configuration de l'application

L'application est configure dans un script portant obligatoirement le nom config.php. Les paramtres de l'applicationsont mis dans un dictionnaire appel $dConfigutilis aussi bien par le contrleur, que les scripts d'actions, lesmodles et vues lmentaires.

III-C - Les bibliothques inclure dans le contrleur

Les bibliothques inclure dans le code du contrleur sont places dans le tableau $dConfig['includes']. Lecontrleur les inclut avec la squence de code suivante :

// lecture config

include"config.php";

// inclusion de bibliothques

for($i=0;$i


12/58




III-D - La gestion des sessions

Le contrleur gnrique gre automatiquement une session. Il sauvegarde et rcupre le contenu d'une session viale dictionnaire $dSession. Ce dictionnaire peut contenir des objets qu'il faut srialiser pour pouvoir les rcuprerensuite correctement. La cl associe ce dictionnaire est 'session'. Aussi rcuprer une session se fait avec le

code suivant :

// on dmarre ou reprend la session

session_start();

$dSession=$_SESSION["session"];

if($dSession) $dSession=unserialize($dSession);

Si une action souhaite mmoriser des informations dans la session, elle ajoutera des cls et des valeurs dans ledictionnaire $dSession. Toutes les actions partageant la mme session, il y a un risque de conflit de cls de sessionsi l'application est dveloppe indpendamment par plusieurs personnes. C'est une difficult. Il faut dvelopper unrfrentiel listant les cls de session, rfrentiel partag par tous. Nous verrons que chaque action se termine parl'appel la fonction finSessionsuivante :

// ---------------------------------------------------------------

functionfinSession(&$dConfig,&$dReponse,&$dSession){

// $dConfig : dictionnaire de configuration

// $dSession : dictionnaire contenant les infos de session

// $dReponse : le dictionnaire des arguments de la page de rponse

// enregistrement de la session

if(isset($dSession)){

// on met les paramtres de la requte dans la session

$dSession['requete']=strtolower($_SERVER['REQUEST_METHOD'])=='get'?$_GET:

strtolower($_SERVER['REQUEST_METHOD'])=='post'?$_POST:array();

$_SESSION['session']=serialize($dSession);

session_write_close();

}else{

// pas de session

session_destroy();

}



// fin du script

exit(0);

}//finsession

Une action peut dcider de ne pas poursuivre une session. Il lui suffit pour cela de ne pas passer de valeurau paramtre $dSession de la fonction finSession, auquel cas la session est supprime (session_destroy).Si le dictionnaire $dSession existe, il est sauvegard dans la session et celle-ci est ensuite enregistre(session_write_close). L'action en cours peut donc mmoriser des lments dans la session en ajoutant des lmentsau dictionnaire $dSession. On notera que le contrleur mmorise automatiquement les paramtres de la requtecourante dans la session. Cela permettra de les rcuprer si besoin est pour traiter la requte suivante.

III-E - L'excution des actions

Le contrleur attend des requtes ayant un paramtre action=XX. Si ce paramtre n'existe pas dans la requte etque celle-ci est un GET, l'action prend la valeur 'get:init'. C'est le cas de la toute premire requte faite au contrleuret qui est de la forme http://machine:port/chemin/main.php.

// on rcupre l'action entreprendre $sAction=$_GET['action']?strtolower($_GET['action']) :'init';

$sAction=strtolower($_SERVER['REQUEST_METHOD']).":$sAction";


13/58




Par configuration, chaque action est associ un script charg de traiter cette action. Par exemple :

// configuration des actions de l'application

$dConfig['actions']['get:init']=array('url'=>'a-init.php');

$dConfig['actions']['post:calculerimpot']=array('url'=>'a-calculimpot.php');

$dConfig['actions']['get:retourformulaire']=array('url'=>'a-retourformulaire.php'); $dConfig['actions']['post:effacerformulaire']=array('url'=>'a-init.php');

$dConfig['actions']['enchainementinvalide']=array('url'=>'a-enchainementinvalide.php');

$dConfig['actions']['actioninvalide']=array('url'=>'a-actioninvalide.php');

Deux actions sont prdfinies :

enchainementinvalide cas o l'action en cours ne peut suivrel'action prcdente

actioninvalide cas o l'action demande n'existe pas dansle dictionnaire des actions

Les actions propres l'application sont notes sous la forme mthode:actiono mthode est la mthode getou postde la requte et action l'action demande, ici : init, calculerimpot, retourformulaire, effacerformulaire. On remarqueraque l'action est rcupre, quelque soit la mthode GET ou POST d'envoi des paramtres, par la $_GET['action']:

// on rcupre l'action entreprendre

$sAction=$_GET['action']?strtolower($_GET['action']) :'init';


En effet, mme si un formulaire est post, on peut toujours crire :

..

Les lments du formulaire seront posts (method='post'). Nanmoins l'url demande sera main.php?action=calculerimpot. Les paramtres de cette URL seront rcuprs dans le dictionnaire $_GETalors que lesautres lments du formulaire seront eux rcuprs dans le dictionnaire $_POST.

Muni du dictionnaire des actions, le contrleur excute l'action demande de la faon suivante :

// traitement de l'action

$scriptAction=$dConfig['actions'][$sAction]?

$dConfig['actions'][$sAction]['url']: $dConfig['actions']['actioninvalide']['url'];

include$scriptAction;

Si l'action demande n'est pas dans le dictionnaire des actions, c'est le script correspondant une action invalide quisera excut. Une fois le script de l'action charg au sein du contrleur, il s'excute. On remarquera qu'il a accs auxvariables du contrleur ($dConfig, $dSession) ainsi qu'aux dictionnaires super-globaux de PHP ($_GET, $_POST,$_SERVER, $_ENV, $_SESSION). On trouvera dans le script, de la logique applicative et des appels des classesmtier. Dans tous les cas, l'action devra

1 Renseigner le dictionnaire $dSessionsi des lments doivent tre sauvegards dans la session courante2 Indiquer dans $dReponse['vuereponse']le nom du modle de rponse afficher3 Se terminer par l'appel finSession($dConfig, $dReponse, $dSession). Si la session doit tre dtruite,

l'action se terminera simplement par l'appel finSession($dConfig, $dReponse).


14/58




Par souci de cohrence, l'action pourra mettre dans le dictionnaire $dReponsetoutes les informations dont ont besoinles vues. Mais il n'y a pas d'obligation. Seule la valeur$dReponse['vuereponse']est indispensable. On remarqueraque tout script d'action se termine par l'appel la fonction finSessionqui elle-mme se termine par une oprationexit. On ne revient donc pas d'un script d'action.

III-F - L'enchanement des actionsOn peut voir une application web comme un automate tats finis. Les diffrents tats de l'application sont associsaux vues prsentes l'utilisateur. Celui-ci par le biais d'un lien ou d'un bouton va passer une autre vue. L'applicationweb a chang d'tat. Nous avons vu qu'une action tait initie par une requte du genre http://machine:port/chemin/main.php?action=XX. Cette URL doit provenir d'un lien contenu dans la vue prsente l'utilisateur. On veut en effetviter qu'un utilisateur tape directement l'URL http://machine:port/chemin/main.php?action=XXcourt-circuitantainsi le cheminement que l'application a prvu pour lui. Ceci est vrai galement si le client est un programme.

Un enchanement sera correct si l'URL demande est une URL qui peut tre demande partir de la dernire vueprsente l'utilisateur. La liste de celles-ci est simple dterminer. Elle est constitue

Des URL contenues dans la vue soit sous forme de liens sois sous forme de cibles d'actions de type [submit]

Des URL qu'un utilisateur est autoris taper directement dans son navigateur lorsque la vue lui estprsente.

La liste des tats de l'applications ne se confond pas ncessairement avec celle des vues. Considrons parexemple une vue lmentaire erreurs.phpsuivante :

Les erreurs suivantes se sont produites :


15/58




autorise pour l'action et le nom de celleci. Dans l'exemple ci-dessus, il y a quatre actions possibles : get:init,post:alculerimpot, get:retourformulaire et post:effacerformulaire.

Muni du dictionnaire $dConfig['etats'], le contrleur peut dire si l'action $sActionen cours est autorise ou non dansl'tat actuel de l'application. Celui est construit par chaque action et stock dans la session dans $dSession['etat'].Le code du contrleur pour vrifier si l'action courante est autorise ou non est le suivant :

.....

// l'enchanement des actions est-il normal ?

if( !enchainementOK($dConfig,$dSession,$sAction)){

// enchanement anormal

$sAction='enchainementinvalide';

}//if



$dConfig['actions'][$sAction]['url']:

$dConfig['actions']['actioninvalide']['url'];


..........

//--------------------------------------------------------------------

functionenchainementOK(&$dConfig,&$dSession,$sAction){ // vrifie si l'action courante est autorise vis vis de l'tat prcdent




$actionsautorisees=$dConfig['etats'][$etat]['actionsautorisees'];

$autorise=!isset($actionsautorisees) ||in_array($sAction,$actionsautorisees);

return$autorise;

}

La logique est la suivante : une action $sActionest autorise si elle se trouve dans la liste $dConfig['etats'][$etat]['actionsautorisees']ou si cette liste est inexistante autorisant alors toute action. $etatest l'tat de l'application lafin du prcdent cycle demande client/rponse serveur. Cet tat a t stock dans la session et est retrouv l. Si ondcouvre que l'action demande est illgale, on fait excuter le script $dConfig['actions']['enchainementinvalide']['url']. Ce script se chargera de transmettre une rponse adquate au client.

En phase de dveloppement, on pourra ne pas remplir le dictionnaire $dConfig['etats']. Dans ce cas, tout tatautorise toute action. On pourra mettre au point le dictionnaire lorsque l'application aura t totalement dbogue.Il protgera l'application d'actions non autorises.

III-G - L'envoi de la rponse au client

Le script [$scriptAction]de traitement de l'action courante place dans $dSession['etat']['principal'], l'tat dans

lequel doit tre place l'application. Cet tat est l'une des cls du dictionnaire des tats $dConfig['etats']. Dansl'exemple suivant :

// configuration des tats de l'application

$dConfig['etats']['e-formulaire']=array(

'actionsautorisees'=>array('post:calculerimpot','get:init','post:effacerformulaire'),

'vue'=>'e-formulaire.php');

$dConfig['etats']['e-erreurs']=array(

'actionsautorisees'=>array('get:retourformulaire','get:init'),

'vue'=>'e-erreurs.php');

$dConfig['etats']['sansetat']=array('actionsautorisees'=>array('get:init'));

On a deux tats appels [e-formulaire] et [e-erreurs]. A un tat correspond un gnrateur de rponse et un seul.Ce gnrateur doit gnrer la rponse/vue envoyer au client. Dans l'exemple ci-dessus, si un script d'action
http://tahe.developpez.com/web/php/mvc/http://tahe.developpez.com/web/php/mvc/http://tahe.developpez.com/web/php/mvc/http://tahe.developpez.com/web/php/mvc/http://tahe.developpez.com/mailto:[email protected]://www.developpez.com/


16/58




[$scriptAction] indique que l'application doit tre mise dans l'tat [e-formulaire], alors le contrleur demanderal'excution du script [e-formulaire.php]. Ceci est ralis par la squence de code suivante dans le contrleur :

// envoi de la rponse(vue) au client

$sEtat=$dSession['etat']['principal'];

$scriptVue=$dConfig['etats'][$sEtat]['vue'];

include$scriptVue;

Le gnrateur de vue [$scriptVue] va s'excuter et prparer la vue envoyer. Chaque gnrateur de vue se terminepar un appel la procdure [finSession]du contrleur gnrique. Celle-ci a pour objectif :

D'envoyer l'utilisateur la vue prpare par le gnrateur [$scriptVue]

D'enregistrer certaines informations dans la session

De terminer l'excution du contrleur (exit)

Nous avons dit qu'une rponse pouvait avoir diffrents modles de page. Ceux-ci sont placs par configuration dans

['vuesReponse']. Dans une application deux modles, on pourrait ainsi avoir :

$dConfig['vuesReponse']['modele1']=array('url'=>'m-modele1.php');

$dConfig['vuesReponse']['modele2']=array('url'=>'m-modele2.php');

Le gnrateur de vue prcise dans $dReponse['vuereponse']le modle de la rponse dsire. Par exemple :

$dReponse['vueReponse']='modele1';

La rponse est envoye au client par le contrleur gnrique avec l'instruction :



Dans notre exemple, cela revient crire :

include'm-modele1.php';

Le script [m-modele1.php] s'excute. C'est une page PHP de prsentation, sans logique de programmation mais avecdes lments dynamiques. Une fois cette page envoye au client, le contrleur s'arrte (exit). Le cycle demande-rponse du client-serveur est termin.

III-H - Dbogage

Le contrleur propose deux fonction de dbogage :

La fonction tracepermet d'afficher un message dans le flux html

La fonction dumppermet d'afficher le contenu d'un dictionnaire dans ce mme flux

Tout script d'action pourra utiliser ces deux fonctions. En effet, le code du script d'action tant inclus (include) dans

le code du contrleur, les fonctions traceet dumpseront visibles des scripts.


17/58




III-I - Conclusion

Le contrleur gnrique vise permettre au dveloppeur de se concentrer sur les actions et les vues de sonapplication. Il assure pour lui :

La gestion de la session (restauration, sauvegarde)

La vrification de la validit des actions demandes

L'excution du script associ l'action

L'envoi au client de la rponse adapte l'tat rsultat de l'excution de l'action


18/58




IV - Une application d'illustration

Nous nous proposons d'illustrer la mthode prcdente avec un exemple de calcul d'impts.

IV-A - Le problme

on dsire crire une application permettant un utilisateur de calculer son impt sur le web. On se place dans le cassimplifi d'un contribuable n'ayant que son seul salaire dclarer (chiffres 2004 pour revenus 2003) :

On calcule le nombre de parts du salari nbParts=nbEnfants/2 +1s'il n'est pas mari, nbEnfants/2+2s'il estmari, o nbEnfantsest son nombre d'enfants.

S'il a au moins trois enfants, il a une demi part de plus

On calcule son revenu imposable R=0.72*S o S est son salaire annuel

On calcule son coefficient familialQF=R/nbParts

On calcule son imptI. Considrons le tableau suivant :

Chaque ligne a 3 champs. Pour calculer l'impt I, on recherche la premire ligne o QF


19/58




IV-C - L'architecture MVC de l'application

L'application aura l'architecture MVC suivante :

Le contrleur main.phpsera le contrleur gnrique expos prcdemment

La demande du client est envoye au contrleur sous la forme d'une requte de la forme main.php?action=xx.La valeur du paramtre action dtermine le script du bloc ACTIONS excuter. Le script d'actionexcut rend au contrleur une variable indiquant l'tat dans lequel doit tre place l'application web. Muni decet tat, le contrleur va activer l'un des gnrateurs de vues pour envoyer la rponse au client.

c-impots-data.phpest la classe charge de fournir au contrleur les donnes dont il a besoin

c-impots-calcul.phpest la classe mtier permettant le calcul de l'impt

IV-D - La classe d'accs aux donnes

La classe d'accs aux donnes est construite pour cacher l'application web la provenance des donnes. Dansson interface, on trouve une mthode getDataqui dlivre les trois tableaux de donnes ncessaires au calcul del'impt. Dans notre exemple, les donnes sont prises dans une base de donnes MySQL. Afin de rendre la classeindpendante du type rel du SGBD, nous utiliserons la bibliothque pear::DBdcrite en annexe. Le code [c-impots-data.php]de la classe est le suivant :


20/58




class impots_data{

// classe d'accs la source de donnes DBIMPOTS

// attributs

var$sDSN;// la chane de connexion

var$sDatabase;// le nom de la base

var$oDB;// connexion la base

var$aErreurs;// liste d'erreurs

var$oRsultats;// rsultat d'une requte

var$connect;// boolen qui indique si on est connect ou non la base

var$sQuery;// la dernire requte excute

// constructeur

functionimpots_data($dDSN){

// $dDSN : dictionnaire dfinissant la liaison tablir

// $dDSN['sgbd'] : le type du SGBD auquel il faut se connecter

// $dDSN['host'] : le nom de la machine hte qui l'hberge

// $dDSN['database'] : le nom de la base laquelle il faut se connecter

// $dDSN['user'] : un utilisateur de la bse

// $dDSN['mdp'] : son mot de passe

// cre dans $oDB une connexion la base dfinie par $dDSN sous l'identit de $dDSN['user']

// si la connexion russit // met dans $sDSN la chane de connexion la base

// met dans $sDataBase le nom de la base laquelle on se connecte

// met $connect vrai

// si la connexion choue

// met les msg d'erreurs adquats dans la liste $aErreurs

// ferme la connexion si besoin est

// met $connect faux

// raz liste des erreurs

$this->aErreurs=array();

// on cre une connexion la base $sDSN

$this-

>sDSN=$dDSN["sgbd"]."://".$dDSN["user"].":".$dDSN["mdp"]."@".$dDSN["host"]."/".$dDSN

["database"]; $this->sDatabase=$dDSN["database"];

$this->connect();

// connect ?

if( !$this->connect) return;

// la connexion a russi

$this->connect=TRUE;

}//constructeur

// ------------------------------------------------------------------

functionconnect(){

// (re)connexion la base

// raz liste des erreurs

$this->aErreurs=array();

// on cre une connexion la base $sDSN

$this->oDB=DB::connect($this->sDSN,true);

// erreur ?

if(DB::iserror($this->oDB)){

// on note l'erreur

$this->aErreurs[]="Echec de la connexion la base [".$this->sDatabase."] : [".$this->oDB-

>getMessage()."]";

// la connexion a chou

$this->connect=FALSE;

// fin

return;

}

// on est connect $this->connect=TRUE;

}//connect


21/58




// ------------------------------------------------------------------

functiondisconnect(){

// si on est connect, on ferme la connexion la base $sDSN

if($this->connect){

$this->oDB->disconnect();

// on est dconnect

$this->connect=FALSE;

}//if

}//disconnect

// -------------------------------------------------------------------

functionexecute($sQuery){

// $sQuery : requte excuter

// on mmorise la requte

$this->sQuery=$sQuery;

// est-on connect ?

if(!$this->connect){

// on note l'erreur

$this->aErreurs[]="Pas de connexion existante la base [$this->sDatabase]";

// fin

return; }//if

// excution de la requte

$this->oRsultats=$this->oDB->query($sQuery);

// erreur ?

if(DB::iserror($this->oRsultats)){

// on note l'erreur

$this->aErreurs[]="Echec de la requte [$sQuery] : [".$this->oRsultats->getMessage()."]";

// retour

return;

}//if

}//execute

// ------------------------------------------------------------------ functiongetData(){

// on rcupre les 3 sries de donnes limites, coeffr, coeffn

$this->execute('select limites, coeffR, coeffN from impots');

// des erreurs ?

if(count($this->aErreurs)!=0) returnarray();

// on parcourt le rsultat du select

while($ligne=$this->oRsultats->fetchRow(DB_FETCHMODE_ASSOC)) {

$limites[]=$ligne['limites'];

$coeffr[]=$ligne['coeffR'];

$coeffn[]=$ligne['coeffN'];

}//while

returnarray($limites,$coeffr,$coeffn);

}//getDataImpots

}//classe

?>

Un programme de test [t-impots-data.php]pourrait tre le suivant :


22/58




"sgbd"=>"mysql",

"user"=>"seldbimpots",

"mdp"=>"mdpseldbimpots",

"host"=>"localhost",

"database"=>"dbimpots"

);

// ouverture de la session

$oImpots=newimpots_data($dDSN);

// erreurs ?

if(checkErreurs($oImpots)){

exit(0);

}

// suivi

echo"Connect la base...\n";

// rcupration des donnes limites, coeffr, coeffn

list($limites,$coeffr,$coeffn)=$oImpots->getData();

// erreurs ?

if( !checkErreurs($oImpots)){

// contenu

echo"donnes : \n";

for($i=0;$idisconnect();

// suivi

echo"Dconnect de la base...\n";

// fin

exit(0);

// ----------------------------------

functioncheckErreurs(&$oImpots){

// des erreurs ?

if(count($oImpots->aErreurs)!=0){

// affichage for($i=0;$iaErreurs);$i++){

echo$oImpots->aErreurs[$i]."\n";

}//for

// des erreurs

returntrue;

}//if

// pas d'erreurs

returnfalse;

}//checkErreurs

?>

L'excution de ce programme de test donne les rsultats suivants :

Connect la base...

donnes :

[4262,0,0]

[8382,0.0683,291.09]

[14753,0.1914,1322.92]

[23888,0.2826,2668.39]

[38868,0.3738,4846.98]

[47932,0.4262,6883.66]

[0,0.4809,9505.54]

Dconnect de la base...


23/58




IV-E - La classe de calcul de l'impt

Cette classe permet de calculer l'impt d'un contribuable. On fournit son constructeur les donnes permettant cecalcul. Il se charge ensuite de calculer l'impt correspondant. Le code [c-impots-calcul.php]de la classe est lesuivant :


24/58





exit(0);

}

// suivi

echo"Connect la base...\n";



// erreurs ?


exit(0);

}

// on se dconnecte

$oImpots->disconnect();

// suivi

echo"Dconnect de la base...\n";

// calcul d'un impt

$dData=array('limites'=>&$limites,'coeffr'=>&$coeffr,'coeffn'=>&$coeffn);

$dPerso=array('enfants'=>2,'salaire'=>60000,'mari'=>true,'impot'=>0);

newimpots_calcul($dPerso,$dData);

dump($dPerso);

$dPerso=array('enfants'=>2,'salaire'=>60000,'mari'=>false,'impot'=>0);


dump($dPerso); $dPerso=array('enfants'=>3,'salaire'=>60000,'mari'=>false,'impot'=>0);


dump($dPerso);

$dPerso=array('enfants'=>3,'salaire'=>60000,'mari'=>true,'impot'=>0);


dump($dPerso);

// fin

exit(0);

// ----------------------------------

functioncheckErreurs(&$oImpots){

// des erreurs ?

if(count($oImpots->aErreurs)!=0){

// affichage for($i=0;$iaErreurs);$i++){

echo$oImpots->aErreurs[$i]."\n";

}//for

// des erreurs

returntrue;

}//if

// pas d'erreurs

returnfalse;

}//checkErreurs

?>

L'excution de ce programme de tests donne les rsultats suivants :

Connect la base...

Dconnect de la base...

[enfants,2] [salaire,60000] [mari,1] [impot,4299]




IV-F - Le fonctionnement de l'application

Lorsque l'application web de calcul de l'impt est lance, on obtient la vue [v-formulaire]suivante :


25/58




L'utilisateur remplit les champs et demande le calcul de l'impt :

Il obtient la rponse suivante :


26/58




On remarquera que le formulaire est rgnr dans l'tat o l'utilisateur l'a valid et qu'il affiche de plus le montantde l'impt payer. L'utilisateur peut faire des erreurs de saisie. Celles-ci lui sont signales par une page d'erreursqu'on appelera la vue [verreurs].

Le lien [Retour au formulaire de saisie] permet l'utilisateur de retrouver le formulaire tel qu'il l'a valid.


27/58




Enfin le bouton [Effacer le formulaire] remet le formulaire dans son tat initial, c.a.d. tel que l'utilisateur l'a reu lorsde la demande initiale. C'est un simple bouton HTML de type [Reset].

IV-G - Retour sur l'architecture MVC de l'application

L'application a l'architecture MVC suivante :

Nous venons de dcrire les deux classes c-impots-data.phpet c-impots-calcul.php. Nous dcrivons maintenantles autres lments de l'architecture de notre application.

IV-H - Le contrleur de l'application

Le contrleur main.phpde l'application est celui qui a t dcrit dans la premire partie de ce document. C'est uncontrleur gnrique indpendant de l'application.


28/58





session_start();

$dSession=$_SESSION["session"];

if($dSession) $dSession=unserialize($dSession);








}//if



$dConfig['actions'][$sAction]['url']:

$dConfig['actions']['actioninvalide']['url'];



$sEtat=$dSession['etat']['principal']; $scriptVue=$dConfig['etats'][$sEtat]['vue'];

include$scriptVue;

// fin du script - on ne devrait pas arriver l sauf bogue

trace ("Erreur de configuration.");

trace("Action=[$sAction]");

trace("scriptAction=[$scriptAction]");

trace("Etat=[$sEtat]");

trace("scriptVue=[$scriptVue]");

trace ("Vrifiez que les script existent et que le script [$scriptVue] se termine par l'appel

finSession.");

exit(0);

// ---------------------------------------------------------------

functionfinSession(&$dConfig,&$dReponse,&$dSession){ // $dConfig : dictionnaire de configuration




if(isset($dSession)){

// on met les paramtres de la requte dans la session

$dSession['requete']=strtolower($_SERVER['REQUEST_METHOD'])=='get'?$_GET:

strtolower($_SERVER['REQUEST_METHOD'])=='post'?$_POST:array();

$_SESSION['session']=serialize($dSession);

session_write_close();

}else{

// pas de session

session_destroy();

}



// fin du script

exit(0);

}//finsession

//--------------------------------------------------------------------

functionenchainementOK(&$dConfig,&$dSession,$sAction){

// vrifie si l'action courante est autorise vis vis de l'tat prcdent




$actionsautorisees=$dConfig['etats'][$etat]['actionsautorisees']; $autorise=!isset($actionsautorisees) ||in_array($sAction,$actionsautorisees);

return$autorise;


29/58




}

//--------------------------------------------------------------------

functiondump($dInfos){

// affiche un dictionnaire d'informations

while(list($cl,$valeur)=each($dInfos)){

echo"[$cl,$valeur]
\n";

}//while

}//suivi

//--------------------------------------------------------------------

functiontrace($msg){

echo$msg."
\n";

}//suivi

?>

IV-I - Les actions de l'application web

Il y a quatre actions :

1 get:init : c'est l'action qui est dclenche lors de la demande initiale sans paramtres au contrleur. Ellegnre la vue [v-formulaire]vide.

2 post:effacerformulaire: action dclenche par le bouton [Effacer le formulaire]. Elle gnre la vue [v-formulaire]vide.

3 post:calculerimpot: action dclenche par le bouton [Calculer l'impt]. Elle gnre soit la vue [v-formulaire]avec le montant de l'impt payer, soit la vue [v-erreurs].

4 get:retourformulaire: action dclenche par le lien [Retour au formulaire de saisie]. Elle gnre la vue[vformulaire]pr-remplie avec les donnes errones.

Ces actions sont configures de la faon suivante dans le fichier de configuration :

// configuration des actions de l'application $dConfig['actions']['get:init']=array('url'=>'a-init.php');


$dConfig['actions']['get:retourformulaire']=array('url'=>'a-retourformulaire.php');

$dConfig['actions']['post:effacerformulaire']=array('url'=>'a-init.php');


$dConfig['actions']['actioninvalide']=array('url'=>'a-actioninvalide.php');

chaque action, est associ le script charg de la traiter. Chaque action va emmener l'application web dans untat enregistr dans l'lment $dSession['etat']['principal']. Cet tat est destin tre sauvegard dans la sessionet c'est pourquoi il est plac dans le dictionnaire $dSession. Par ailleurs, l'action enregistre dans le dictionnaire$dReponse, les informations utiles pour l'affichage de la vue lie au nouvel tat dans lequel va se trouver l'application.

IV-J - Les tats de l'application web

Il y en a deux :

[e-formulaire]: tat o sont prsentes les diffrentes variantes de la vue[v-formulaire].

[e-erreurs]: tat o est prsente la vue [v-erreurs].

Les actions autorises dans ces tats sont les suivantes :


$dConfig['etats']['formulaire']=array(

'actionsautorisees'=>array('post:calculerimpot','get:init','post:effacerformulaire'), 'vue'=>'e-formulaire.php');

$dConfig['etats']['erreurs']=array(


30/58







Dans un tat, les actions autorises correspondent aux URL cibles des liens ou boutons [submit] de la vue associe

l'tat. De plus, l'action 'get:init'est tout le temps autorise. Cela permet l'utilisateur de rcuprer l'URL main.phpdans la liste des URL de son navigateur et de la rejouer quelque soit l'tat de l'application. C'est une sorte derinitialisation ' la main'. L'tat 'sansetat'n'existe qu'au dmarrage de l'application.

chaque tat de l'application est associ un script charg de gnrer la vue associe l'tat :

tat [e-formulaire]: script e-formulaire.php

tat [e-erreurs]: script e-erreurs.php

L'tat [e-formulaire]va prsenter la vue [v-formulaire]avec des variantes. En effet, la vue [v-formulaire]peuttre prsente vide ou pr-remplie ou avec le montant de l'impt. L'action qui amnera l'application dans l'tat

[e-formulaire]prcise dans la variable $dSession['etat']['principal']l'tat principal de l'application. Le contrleurn'utilise que cette information. Dans notre application, l'action qui amne l'tat [e-formulaire] ajoutera dans$dSession['etat']['secondaire']une information complmentaire permettant au gnrateur de la rponse de savoirs'il doit gnrer un formulaire vide, pr-rempli, avec ou sans le montant de l'impt. On aurait pu procder diffremmenten estimant qu'il y avait l trois tats diffrents et donc trois gnrateurs de vue crire.

IV-K - Le fichier config.php de configuration de l'application web


31/58






// configuration modle de l'application

$dConfig["DSN"]=array(

"sgbd"=>"mysql",

"user"=>"seldbimpots",

"mdp"=>"mdpseldbimpots",

"host"=>"localhost",

"database"=>"dbimpots"

);

?>

IV-L - Les actions de l'application web

IV-L-1 - Fonctionnement gnral des scripts d'action

Un script d'action est appel par le contrleur selon le paramtre action que celui-ci a reu du client.

Aprs excution, le script d'action doit indiquer au contrleur l'tat dans lequel placer l'application. Cet tatdoit tre indiqu dans $dSession['etat']['principal'].

Un script d'action peut vouloir placer des informations dans la session. Il le fait en plaant celles-ci dans ledictionnaire $dSession, ce dictionnaire tant automatiquement sauvegard dans la session par le contrleur la fin du cycle demande-rponse.

Un script d'action peut avoir des informations passer aux vues. Cet aspect est indpendant du contrleur. Ils'agit de l'interface entre les actions et les vues, interface propre chaque application. Dans l'exemple tudiici, les actions fourniront des informations aux gnrateurs de vues via un dictionnaire appel $dReponse.

IV-L-2 - L'action get:init

C'est l'action qui gnre le formulaire vide. Le fichier de configuration montre qu'elle sera traite par le script a-init.php:

$dConfig['actions']['get:init']=array('url'=>'a-init.php');

Le code du script a-init.phpest le suivant :

Ce script se contente de fixer dans $dSession['etat']['principal']l'tat dans lequel doit se trouver l'application, l'tat[eformulaire]et amne dans $dSession['etat']['secondaire']une prcision sur cet tat. Le fichier de configurationnous montre que le contrleur excutera le script e-formulaire.phppour gnrer la rponse au client.




Le script e-formulaire.phpgnrera la vue [v-formulaire]dans sa variante [init], c.a.d. le formulaire vide.
http://tahe.developpez.com/web/php/mvc/http://tahe.developpez.com/web/php/mvc/http://tahe.developpez.com/web/php/mvc/http://tahe.developpez.com/web/php/mvc/http://tahe.developpez.com/web/php/mvc/http://tahe.developpez.com/web/php/mvc/http://tahe.developpez.com/web/php/mvc/http://tahe.developpez.com/mailto:[email protected]://www.developpez.com/


32/58




IV-L-3 - L'action post:calculerimpot

C'est l'action qui permet de calculer l'impt partir des donnes saisies dans le formulaire. Le fichier de configurationindique que c'est le script a-calculimpot.phpqui va traiter cette action :


Le code du script a-calculimpot.phpest le suivant :


33/58




// connexion la source de donnes dfinie par le dictionnaire $dDSN

$oImpots=newimpots_data($dDSN);

if(count($oImpots->aErreurs)!=0) returnarray($oImpots->aErreurs);



// on se dconnecte

$oImpots->disconnect();

// on rend le rsultat

if(count($oImpots->aErreurs)!=0) returnarray($oImpots->aErreurs);

elsereturnarray(array(),$limites,$coeffr,$coeffn);

}//getData

Le script fait ce qu'il a faire : calculer l'impt. Nous laissons au lecteur le soin de dcrypter le code du traitement.Nous nous intressons aux tats qui peuvent survenir la suite de cette action :

Les donnes saisies sont incorrectes ou l'accs aux donnes se passe mal : l'application est mise dans l'tat[e-erreurs]. Le fichier de configuration montre que c'est le script e-erreurs.phpqui sera charg de gnrer lavue rponse :




Dans tous les autres cas, l'application est place dans l'tat [e-formulaire] avec la variante calculimpotindique dans $dSession['etat']['secondaire']. Le fichier de configuration montre que c'est le script e-formulaire.phpqui va gnrer la vue rponse. Il utilisera la valeur de $dSession['etat']['secondaire']pourgnrer un formulaire pr-rempli avec les valeurs saisies par l'utilisateur et de plus le montant de l'impt.

IV-L-4 - L'action get:effacerformulaire

Elle est associe par configuration au script a-init.phpdj dcrit.

$dConfig['actions']['post:effacerformulaire']=array('url'=>'a-init.php');

IV-L-5 - L'action get:retourformulaire

Elle permet de revenir l'tat [e-formulaire] partir de l'tat [e-erreurs]. C'est le script [a-retourformulaire.php]qui traite cette action :

$dConfig['actions']['get:retourformulaire']=array('url'=>'a-retourformulaire.php');

Le script a-retourformulaire.phpest le suivant :


34/58




On demande simplement ce que l'application soit plac dans l'tat [e-formulaire] dans sa variante[retourformulaire]. Le fichier de configuration nous montre que le contrleur excutera le script e-formulaire.phppour gnrer la rponse au client.




Le script e-formulaire.phpgnrera la vue [v-formulaire]dans sa variante [retourformulaire], c.a.d. le formulairepr-rempli avec les valeurs saisies par l'utilisateur mais sans le montant de l'impt.

IV-M - L'enchanement d'actions invalide

Les actions valides partir d'un tat donn de l'application sont fixes par configuration :









Nous avons dj expliqu cette configuration. Si un enchanement invalide d'actions est dtect, le script[aenchainementinvalide.php]s'excute :


Le code de ce script est le suivant :


35/58




IV-N - Les vues de l'application

IV-N-1 - Affichage de la vue finale

Regardons comment le contrleur envoie la rponse au client, une fois excute l'action demande par celui-ci :

....


session_start();

$dSession=$_SESSION["session"]; if($dSession) $dSession=unserialize($dSession);








}//if



$dConfig['actions'][$sAction]['url']: $dConfig['actions']['actioninvalide']['url'];



$sEtat=$dSession['etat']['principal'];

$scriptVue=$dConfig['etats'][$sEtat]['vue'];

include$scriptVue;

.....

// ---------------------------------------------------------------






...


36/58




// envoi de la rponse au client


// fin du script

exit(0);

}//finsession

Au retour d'un script d'action, le contrleur rcupre dans $dSession['etat']['principal'] l'tat dans lequel il doitmettre l'application. Cet tat a t fix par l'action qui vient d'tre excute. Le contrleur fait alors excuter legnrateur de vue associe l'tat. Il trouve le nom de celui-ci dans le fichier de configuration. Le rle du gnrateurde vue est le suivant :

Il fixe dans $dReponse['vuereponse']le nom du modle de rponse utiliser. Cette information sera passeau contrleur. Un modle est une composition de vues lmentaires qui, rassembles, forment la vue finale.

Il prpare les informations dynamiques afficher dans la vue finale. Ce point est indpendant du contrleur. Ils'agit de l'interface entre le gnrateur de vues et la vue finale. Elle est propre chaque application.

Il se termine obligatoirement par l'appel la fonction finSessiondu contrleur. Cette fonction va

Sauvegarder la session

Envoyer la rponse

Le code de la fonction finSessionest le suivant :

// ---------------------------------------------------------------






...

// envoi de la rponse au client


// fin du script

exit(0);

}//finsession

La vue envoye l'utilisateur est dfinie par l'entit $dReponse['vuereponse']qui dfinit le modle utiliser pourla rponse finale.

IV-N-2 - Modle de la rponse

L'application gnrera ses diffrentes rponses selon le modle unique suivant :


37/58




Ce modle est associ la cl modle1 du dictionnaire $dConfig['vuesreponse']dans [config.php]:

$dConfig['vuesReponse']['modele1']=array('url'=>'m-reponse.php');

Le scrip

stahe-php-mvc.pdf

Documents