II. Une démarche de développement MVC en Web/PHP▲
Nous proposons ici une démarche pour le développement d'applications web/php respectant l'architecture MVC. Elle n'est là que pour ouvrir des pistes. Le lecteur l'adaptera à ses goûts et besoins.
- On commencera par définir toutes les vues de l'application. Celles-ci sont les pages web présentées à l'utilisateur. On se placera du point de vue de celui-ci pour dessiner les vues. On distingue trois types de vues :
- Le formulaire de saisie qui vise à obtenir des informations de l'utilisateur. Celui-ci dispose en général d'un bouton pour envoyer au serveur les informations saisies.
- La page de réponse qui ne sert qu'à donner de l'information à l'utilisateur. Celle-ci dispose souvent d'un ou de plusieurs liens permettant à l'utilisateur de poursuivre l'application avec une autre page.
la page mixte : le contrôleur a envoyé au client une page contenant des informations qu'il a générées. Cette même page va servir au client pour fournir au contrôleur 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 déterminera quelles sont les parties dynamiques de celle-ci :
- Les informations à destination de l'utilisateur qui devront être fournies par le contrôleur en paramètres à la vue PHP. Une solution simple est la suivante :
- Le contrôleur met dans un dictionnaire $dReponse les informations qu'il veut fournir à une vue V
- Le contrôleur fait afficher la vue V. Si celle-ci correspond au fichier source V.php, cet affichage est obtenu simplement par l'instruction include V.php.
- L'inclusion précédente est une inclusion de code dans le contrôleur. Le dictionnaire $dReponse renseigné par celui-ci est accessible directement par le code de V.php.
- Les données de saisie qui devront être transmises au programme principal pour traitement. Celles-ci devront faire partie d'un formulaire HTML (balise <form>).
- On pourra schématiser les E/S de chaque vue
- Les entrées sont les données que devra fournir le contrôleur à la page PHP
- Les sorties sont les données que devra fournir la page PHP au contrôleur de l'aplication. Elles font partie d'un formulaire HTML et le contrôleur les récupèrera par une opération du type $_GET["param"] (méthode GET) ou $_POST ["param"] (méthode POST).
- Fréquemment, la page finale envoyée au client n'est pas une vue mais une composition de vues. Par exemple, la page envoyée à un utilisateur peut avoir la forme suivante :
La zone 1 peut être un bandeau de titre, la zone 2 un bandeau de menu, la zone 3 une zone de contenu. En PHP cette 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 réponse faite à l'utilisateur. Dans ce cas, chaque réponse au client devra fixer les trois URL à charger dans les trois zones avant de faire afficher la page réponse. On peut généraliser cet exemple en imaginant qu'il y ait plusieurs modèles possibles pour la page de réponse. La réponse au client devra donc :
- Fixer le modèle à utiliser
- Fixer les éléments (vues élémentaires) à inclure dans celui-ci
- Demander l'affichage du modèle
On écrira le code PHP/HTML de chaque modèle de réponse. Son code est généralement simple. Celui de l'exemple ci-desssus pourrait être :
On utilisera chaque fois que c'est possible une feuille de style afin de pouvoir changer le "look" de la réponse sans avoir à modifier le code PHP/HTML.
- On écrira le code PHP/HTML de chaque vue élémentaire, élément de la page envoyée en réponse au client. Il aura le plus souvent la forme suivante :
On notera qu'une vue élémentaire s'intègre dans un modèle qui les assemble pour en faire une page HTML. Le code HTML de la vue élémentaire vient s'insérer dans le code du modèle présenté à l'étape précédente. Le plus souvent, le code du modèle intègre déjà les balises <html>, <head>, <body>. Il est donc peu fréquent de trouver ces balises dans une vue élémentaire.
On peut procéder aux tests des différents modèles de réponse et vues élémentaires
- Chaque modèle de réponse est testé. Si un modèle s'appelle modele1.php, on demandera avec un navigateur l'URL http://localhost/chemin/modele1.php Le modèle attend des valeurs du contrôleur. Ici on l'appelle directement et non via le contrôleur. Le modèle ne recevra pas les paramètres attendus. Afin que les tests soient néanmoins possibles on initialisera soi-même, avec des constantes, les paramètres attendus dans la page PHP du modèle.
- Chaque modèle est testé ainsi que toutes les vues élémentaires. C'est aussi le moment d'élaborer les premiers éléments des feuilles de style utilisées.
- On écrit ensuite la logique applicative de l'application :
- Le contrôleur ou programme principal gère en général plusieurs actions. Il faut que dans les requêtes qui lui parviennent l'action à accomplir soit définie. Cela peut se faire au moyen d'un paramètre de la requête que nous appellerons ici action :
- Si la requête provient d'un formulaire (<form>), ce paramètre peut être un paramètre caché du formulaire :
<form … action="/C/main.php" method="post" …>
<input type="hidden" name="action" value="uneAction">
…
</form> - Si la requête provient d'un lien, on peut paramétrer celui-ci :
<a href="/C/main.php?action=uneAction">lien</a>
Le contrôleur peut commencer par lire la valeur de ce paramètre puis déléguer le traitement de la requête à un module chargé de traiter ce type de requête. Nous nous plaçons ici dans le cas ou tout est contrôlé par un unique script appelé main.php. Si l'application doit traiter des actions action1, action2…, actionx on peut créer au sein du contrôleur une fonction par action. S'il y a beaucoup d'actions, on peut arriver à un contrôleur "dinosaure". On peut aussi créer des scripts action1.php, action2.php…,actionx.php chargés de traiter chacune des actions. Le contrôleur devant traiter l'acton actionx se contentera de charger le code du script correspondant par une instruction du genre include "actionx.php". L'avantage de cette méthode est qu'on travaille en-dehors du code du contrôleur. Chaque personne de l'équipe de développement peut ainsi travailler sur le script de traitement d'une action actionx de façon relativement indépendante. L'inclusion du code du script actionx.php dans le code du contrôleur au moment de l'exécution a également l'avantage d'alléger le code chargé en mémoire. Seul le code de traitement de l'action en cours est chargé. Cette inclusion de code fait que des variables du contrôleur peuvent entrer en collision avec celles du script de l'action. Nous verrons que nous pouvons faire en sorte de limiter les variables du contrôleur à quelques variables bien définies qu'il faudra alors éviter d'utiliser dans les scripts.
- On cherchera systématiquement à isoler le code métier ou le code d'accès aux données persistantes dans des modules distincts. Le contrôleur est une sorte de chef d'équipe qui reçoit des demandes de ses clients (clients web) et qui les fait exécuter par les personnes les plus appropriées (les modules métier). Lors de l'écriture du contrôleur, on déterminera l'interface des modules métier à écrire. Cela si ces modules métier sont à construire. S'ils existent déjà, alors le contrôleur s'adaptera à l'interface de ces modules existants.
- On écrira le squelette des modules métier nécessaires au contrôleur. Par exemple, si celui-ci utilise un module getCodes rendant un tableau de chaînes de caractères, on peut se contenter dans un premier temps d'écrire :
- On peut alors passer aux tests du contrôleur et des scripts PHP associés :
- Le contrôleur, les scripts d'actions, les modèles, les vues, les ressources nécessaires à l'application (images,…) sont placés dans le dossier DC associé au contexte C de l'application.
- Ceci fait, l'application est testée et les premières erreurs corrigées. Si main.php est le contrôleur et C le 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 opérationnelle. Cette phase de test peut être délicate sachant qu'on n'a peu d'outils de débogage si on n'utilise pas des environnements de développement évolués et en général payants. On pourra s'aider d'instructions echo "message" qui écrivent dans le flux HTML envoyé au client et qui apparaissent donc dans la page web affichée par le navigateur.
- On écrit enfin les classes métier dont a besoin le contrôleur. On a là en général le développement classique d'une classe PHP, développement le plus souvent indépendant de toute application web. Elle sera tout d'abord testée en dehors de cet environnement, avec une application console par exemple. Lorsqu'une classe métier a été écrite, on l'intégre dans l'architecture de déploiement de l'application web et on teste sa correcte intégration. On procèdera ainsi pour chaque classe métier.