Introduction au langage PHP 7 par l'exemple

[Postman] est l’outil qui va nous permettre d’interroger les différentes URL de notre application web. Il nous permet :

• d’utiliser n’importe quelle URL : celles-ci sont fabriquées à la main ;
• de requêter le serveur web par un GET, POST, PUT, OPTIONS… ;
• de préciser les paramètres du GET ou du POST ;
• de fixer les entêtes HTTP de la requête ;
• de recevoir une réponse au format jSON, XML, HTML,
• d’avoir accès aux entêtes HTTP de la réponse. On a donc ainsi accès à la réponse HTTP complète du serveur ;

Puisque nous fabriquons à la main les URL interrogées, nous allons pouvoir tester tous les cas d’erreur possibles et voir comment le serveur réagit.

[Postman] est disponible à l’URL [https://www.getpostman.com/downloads/]. La version disponible en juin 2019 est la 7.2. Cette version présente une anomalie : lorsqu’on fait des requêtes successives au serveur web interrogé, le client [Postman 7.2] ne renvoie pas automatiquement les cookies que le serveur lui envoie, notamment le cookie de session. Pour maintenir la session, il faut alors recopier à la main le cookie de session dans les entêtes HTTP des requêtes successives. Ce n’est pas bien compliqué mais ce n’est pas pratique. C’est un bug qui n’existait pas dans les versions précédentes. Conscient du bug, l’équipe de [Postman] l’a corrigé dans une version alpha (peut être instable) appelée [Postman Canary] disponible à l’URL [https://www.getpostman.com/downloads/canary]. C’est cette version qui est utilisée ici. Nous allons décrire son installation. Si une version stable [Postman 7.3] ou ultérieure est disponible, vous pouvez la télécharger : le bug aura probablement été corrigé.

Procédez à l’installation de votre version de [Postman]. Au cours de l’installation, on vous demandera de créer un compte : celui-ci sera inutile ici. Le compte [Postman] sert à synchroniser différents appareils afin que la configuration de l’un soit répliqué sur un autre. Rien de tout ceci n’est utile ici.

Une fois installé, [Postman] présente l’interface suivante :

• en [2-3], on a accès au paramétrage du produit ;

• en [6], la version utilisée dans ce document ;
• si vous avez créé un compte, une synchronisation se fait entre votre poste et un serveur [Postman] distant. Cela est symbolisé par la roue [7] qui tourne à chaque fois que vous faites des modifications dans le projet [Postman]. Pour arrêter cette synchronisation inutile, déconnectez-vous en [8-9] ;

Pour sérialiser des objets en jSON et XML, nous allons utiliser la bibliothèque [Symfony / Serializer]. Elle présente ici deux avantages :

• elle est homogène dans son utilisation pour sérialiser en jSON ou XML : cela évite d’apprendre deux bibliothèques aux API (Application Programming Interface) différentes ;
• nativement, elle sait sérialiser en jSON ou XML des objets, même si les attributs de ceux-ci sont privés. On se rappelle qu’en jSON, pour sérialiser un objet, il fallait que la classe de celui-ci implémente l’interface [\JsonSerializable]. Le résultat obtenu alors était la chaîne jSON d’un tableau associatif ayant les attributs de la classe pour clés. Lorsqu’on désérialisait cette chaîne jSON, on retrouvait le tableau associatif primitif, qu’il fallait alors transformer en un objet de la classe qui avait été sérialisée. Avec [Symfony / Serializer], la désérialisation produit tout de suite un objet de la classe sérialisée. C’est plus simple ;

La documentation de la bibliothèque [Symfony / Serializer] est disponible à l’URL : [https://symfony.com/doc/current/components/serializer.html] (juin 2019).

Pour installer cette bibliothèque, ouvrez un terminal Laragon (cf paragraphe lienInstallation de Laragon) et tapez la commande suivante :

• en [1], la commande d’installation de la bibliothèque [symfony/serializer] ;
• en [2], une autre bibliothèque nécessaire à notre projet : permet la sérialisation des objets ;

• [1-2] : le contrôleur principal [main.php] [1] est configuré par le fichier [config.json] [2] ;

Rappelons la position du contrôleur principal dans notre architecture MVC :

En [1], le contrôleur principal [main.php] est le 1^er élément de l’architecture MVC à traiter la requête du client. Il a plusieurs rôles :

• il fait d’abord les vérifications de base :
  • est-ce que son fichier de configuration existe et est valide ;
  • chargement de toutes les dépendances du projet. Cela revient à charger tous les éléments de l’architecture MVC ;
  • est-ce que l’action demandée a été précisée ? Si oui, est-elle valide ?
  • si l’action demandée est valide, sélectionner [2a] le contrôleur secondaire qui va la traiter et lui passer les informations dont il a besoin : la requête HTTP, la session, la configuration de l’application ;
  • récupérer [2c] la réponse du contrôleur secondaire. Selon le type (jSON, XML, HTML) d’application demandé par le client, sélectionner [3a] la réponse (JsonResponse, XmlResponse, HtmlResponse) chargée d’envoyer la réponse au client et lui passer toutes les informations dont elle a besoin (la requête HTTP, la session, la configuration de l’application, la réponse du contrôleur secondaire) ;
  • une fois cette réponse envoyée [3c], procéder à la libération des ressources qui ont pu être mobilisées pour le traitement de la requête ;

Le code du contrôleur principal [main.php] est le suivant :

<?php

// respect strict des types déclarés des paramètres de foctions
declare (strict_types=1);

// espace de noms
namespace Application;

// dépendances Symfony
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpFoundation\Session\Session;

// gestion des erreurs par PHP
//ini_set("display_errors", "0");
error_reporting(E_ALL && !E_WARNING && !E_NOTICE);
// on récupère la configuration
$configFilename = "config.json";
$fileContents = \file_get_contents($configFilename);
$erreur = FALSE;
// erreur ?
if (!$fileContents) {
  // on note l'erreur
  $état = 131;
  $erreur = TRUE;
  $message = "Le fichier de configuration [$configFilename] n'existe pas";
}
if (!$erreur) {
  // on récupère le code JSON du fichier de configuration dans un tableau associatif
  $config = \json_decode($fileContents, true);
  // erreur ?
  if (!$config) {
    // on note l'erreur
    $erreur = TRUE;
    $état = 132;
    $message = "Le fichier de configuration [$configFilename] n'a pu être exploité correctement";
  }
}
// erreur ?
if ($erreur) {
  // préparation de la réponse JSON du serveur
  // on ne peut pas s'aider du fichier de configuration
  // dépendances symfony
  require_once "C:/myprograms/laragon-lite/www/vendor/autoload.php";
  // préparation réponse
  $response = new Response();
  $response->headers->set("content-type", "application/json");
  $response->setCharset("utf-8");
  // code de statut
  $response->setStatusCode(Response::HTTP_INTERNAL_SERVER_ERROR);
  // contenu
  $response->setContent(json_encode(["action" => "", "état" => $état, "réponse" => $message], JSON_UNESCAPED_UNICODE));
  // envoi
  $response->send();
  // fin
  exit;
}
…

Commentaires

• lignes 10-12 : le contrôleur principal utilise les objets suivants de Symfony :
  • [Request] : la requête HTTP en cours de traitement ;
  • [Session] : la session de l’application web ;
  • [Response] : la réponse HTTP au client ;
• ligne 15 : pendant tout le développement on gardera cette ligne en commentaires : les erreurs PHP sont alors intégrées dans le flux texte envoyé au client. Si ce client est un navigateur, cela permet de voir les erreurs rencontrées par le serveur. C’est une aide au débogage ;
• ligne 16 : toutes les erreurs sont signalées (E_ALL) sauf les avertissements (! E_WARNING) et les informations non fatales (! E_NOTICE). Par exemple, si un fichier ne peut être ouvert, PHP émet une erreur de type [E_NOTICE]. Si la ligne 15 permet l’affichage des erreurs, l’erreur d’ouverture du fichier apparaît dans le navigateur client. C’est bien si vous avez oublié de tester le résultat de l’ouverture du fichier, moins bien si vous avez prévu le test : une ligne de [notice] vient alors polluer la réponse du serveur au client. En phase de développement, la ligne 16 devrait elle-aussi être commentée : vous ne voulez rater aucune erreur ;
• ligne 19 : le fichier de configuration est lu ;
• lignes 22-27 : si cette lecture s’est mal passée, on note l’erreur (ligne 25), on met l’application dans l’état [131] et on prépare un message d’erreur ;
• ligne 30 : on décode la chaîne jSON du fichier de configuration ;
• lignes 32-37 : si ce décodage se passe mal, on note l’erreur (ligne 34), on met l’application dans l’état [132] et on prépare un message d’erreur ;
• lignes 40-57 : en cas d’erreur de lecture du fichier de configuration, on ne peut plus avancer. On prépare alors une réponse jSON au client :
• ligne 44 : comme le fichier de configuration n’a pas été lu, il faut importer à la main le fichier [autoload] nécessaire à [Symfony] ;
• lignes 46-47 : on prépare une réponse jSON ;
• ligne 50 : le code HTTP de la réponse sera 500 INTERNAL_SERVER_ERROR ;
• ligne 52 : on fixe le contenu jSON de la réponse. Toutes les réponses faites par l’application web étudiée auront trois clés :
  • [action] : l’action demandée par le client ;
  • [état] : l’état de l’application après exécution de cette action ;
  • [réponse] : la réponse du serveur web ;
• ligne 54 : la réponse jSON est envoyée au client ;

Nous allons vérifier le comportement du serveur lorsque fichier de configuration est absent ou incorrect :

Nous allons rassembler les différentes requêtes que notre client [Postman] va émettre vers le serveur d’impôts dans des collections.

• en [1], créez une nouvelle collection ;
• en [2], donnez-lui un nom ;
• en [3], la description est facultative ;

• dans les collections [4], apparaît maintenant une collection nommée [impots-server-tests-version12] [5] ;
• en [6], on peut ajouter une nouvelle requête à la collection ;

• en [7], on donne un nom à la requête ;
• en [8], la description est facultative ;

• en [9-11], la requête ajoutée à la collection ;
• en [12], choix du type de la requête, ici une requête [GET]. En [19], les différents types de requête disponibles ;
• en [13], on tape ici l’URL du serveur ;
• en [14], on met ici les paramètres ajoutés à l’URL et qui seront donc des paramètres du GET. L’intérêt de les mettre ici plutôt que directement dans l’URL est qu’ils seront URL-encodés par [Postman]. Si vous les mettez vous-mêmes dans l’URL ce sera à vous de les URL-encoder ;
• en [15], [Authorization] sert à définir l’utilisateur qui va se connecter. Nous n’aurons pas à utiliser cette possibilité ;
• en [16], les entêtes HTTP qui accompagneront la requête. Un certain nombre d’entêtes sont automatiquement inclus dans la requête. Vous pouvez ici en ajouter de nouveaux ;
• en [17], [Body] désigne les paramètres d’une opération [POST]. Nous aurons à utiliser cette option ;

Nous allons faire le test suivant :

• dans [main.php], on indique que le fichier de configuration est [config2.json] qui n’existe pas :

• la ligne 16 du code doit être décommentée ;
• ligne 18 : l’erreur sur le nom du fichier de configuration ;

Entrons dans [Postman] [13, 20], l’URL du serveur web de calcul d’impôt et exécutons-la [21] :

La réponse renvoyée par le serveur (il faut bien sûr que Laragon soit actif) est la suivante :

• en [22], le serveur a renvoyé un code HTTP [500 Internal Server Error] ;
• en [23], [Body] désigne le corps de la réponse, ç-à-d le document envoyé par le serveur derrière les entêtes HTTP [28] ;
• en [26], on voit que [Postman] a reçu une réponse jSON ;
• en [27], la réponse jSON mise en forme ;
• en [28], la réponse jSON brute sans mise en forme ;
• en [29], le mode [Preview] est utilisé lorsque la réponse est du HTML. Le mode [Preview] affiche alors la page reçue ;
• en [30], la réponse jSON du serveur. C’est bien celle que nous attendions ;

En [25], les entêtes HTTP envoyés dans la réponse du serveur sont les suivants :

• en [32], le type jSON de la réponse ;

Ce premier test nous a permis de voir qu’on :

• peut envoyer tout type de requête au serveur testé ;
• peut fixer les paramètres du GET ou du POST ;
• a la totalité de la réponse : entêtes HTTP et le document qui suit ces entêtes [Body] ;

Maintenant, faisons un second test :

• en [1-3], le fichier [config3.json] est un fichier jSON syntaxiquement incorrect ;
• en [4], [main.php] est configuré pour utiliser [config3.json] ;

Nous ajoutons une nouvelle requête dans [Postman] :

• [1-3], on clique droit sur [2] et on prend l’option [duplicate] pour dupliquer la requête [2] ;
• en [4], la nouvelle requête a un nom prédéfini qu’on change en [5] ;

• en [6], la requête renommée ;
• en [9-10], on envoie la même requête GET que précédemment ;

• en [11], la réponse jSON du serveur ;

Nous avons montré ici comment allaient être testées les différentes actions du service web du calcul de l’impôt.

Nous reprenons l’étude du code du contrôleur principal [main.php] :

<?php

// respect strict des types déclarés des paramètres de foctions
declare (strict_types=1);

// espace de noms
namespace Application;

// dépendances Symfony
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpFoundation\Session\Session;

// gestion des erreurs par PHP
//ini_set("display_errors", "0");
error_reporting(E_ALL && !E_WARNING && !E_NOTICE);
// on récupère la configuration
$configFilename = "config.json";
…
// on inclut les dépendances nécessaires au script
$rootDirectory = $config["rootDirectory"];
foreach ($config["relativeDependencies"] as $dependency) {
  require_once "$rootDirectory$dependency";
}
// dépendances absolues (bibliothèques tierces)
foreach ($config["absoluteDependencies"] as $dependency) {
  require_once "$dependency";
}

// création du fichier des logs
try {
  $logger = new Logger($config['logsFilename']);
} catch (ExceptionImpots $ex) {
  // on n'a pas pu créer le fichier de logs - internal server error
  $état = 133;
  (new JsonResponse())->send(
    NULL, NULL, $config,
    Response::HTTP_INTERNAL_SERVER_ERROR,
    ["action" => "non déterminée", "état" => $état, "réponse" => "Le fichier de logs [{$config['logsFilename']}] n'a pu être créé"],
    []);
  // terminé
  exit;
}

Commentaires

• ligne 18 : on a un fichier de configuration [config.json] désormais existant et syntaxiquement correct. Il faudrait de plus tester que les clés attendues dans ce fichier sont bien présentes. Nous considèrerons que cela fait partie du travail normal de débogage du développeur. Nous aurions pu faire ce même raisonnement pour les deux précédentes erreurs ;
• lignes 20-28 : on inclut toutes les dépendances nécessaires au projet web. Nous avons déjà rencontré ce code plusieurs fois ;
• ligne 31-43 : on essaie de créer l’objet [Logger] qui va nous permettre de loguer des événements dans le fichier [$config['logsFilename']]. Cette création peut échouer ;
• lignes 33-43 : gestion de l’erreur de création de l’objet [Logger] ;
• ligne 35 : on fixe un n° d’état ;
• lignes 36-40 : on envoie une réponse jSON ;
• ligne 42 : on arrête le script ;

Toutes les réponses envoyées au client implémentent l’interface [InterfaceResponse] suivante :

Le code de l’interface [InterfaceResponse] est le suivant :

<?php

namespace Application;

// dépendances Symfony
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Session\Session;

interface InterfaceResponse {

  // Request $request : requête en cours de traitement
  // Session $session : la session de l'application web
  // array $config : la configuration de l'application
  // int statusCode : le code HTTP de statut de la réponse
  // array $content : la réponse du serveur
  // array $headers : les entêtes HTTP à ajouter à la réponse
  // Logger $logger : le logueur pour écrire des logs
  
  public function send(
    Request $request = NULL,
    Session $session = NULL,
    array $config,
    int $statusCode,
    array $content,
    array $headers,
    Logger $logger = NULL): void;
}

• lignes 19-27 : l’interface [InterfaceResponse] a une unique méthode [send] pour envoyer la réponse au client ;
• lignes 11-17 : la signification des différents paramètres de la méthode [send] ;
• lignes 23-25 : les paramètres [$statusCode, $content, $headers] sont dans le résultat standard des contrôleurs secondaires de l’application. Cependant la réponse peut avoir besoin d’autres informations. Aussi lui donne-t-on les trois premiers paramètres (lignes 20-22) qui lui donnent accès à la totalité des informations concernant la requête, la session, la configuration ;
• ligne 26 : la réponse a besoin du [Logger] car elle va loguer la réponse envoyée au client ;

La classe [JsonResponse] implémente l’interface [InterfaceResponse] de la façon suivante :

<?php

namespace Application;

// dépendances Symfony
use Symfony\Component\Serializer\Encoder\JsonEncode;
use Symfony\Component\Serializer\Encoder\JsonEncoder;
use Symfony\Component\Serializer\Normalizer\ObjectNormalizer;
use Symfony\Component\Serializer\Serializer;
use \Symfony\Component\HttpFoundation\Request;
use \Symfony\Component\HttpFoundation\Session\Session;

class JsonResponse extends ParentResponse implements InterfaceResponse {

  // Request $request : requête en cours de traitement
  // Session $session : la session de l'application web
  // array $config : la configuration de l'application
  // int statusCode : le code HTTP de statut de la réponse
  // array $content : la réponse du serveur
  // array $headers : les entêtes HTTP à ajouter à la réponse
  // Logger $logger : le logueur pour écrire des logs

  public function send(
    Request $request = NULL,
    Session $session = NULL,
    array $config,
    int $statusCode,
    array $content,
    array $headers,
    Logger $logger = NULL): void {

    // préparation sérialiseur symfony
    $serializer = new Serializer(
      [
      // nécessaire pour la sérialisation d'objets
      new ObjectNormalizer()],
      // encodeur jSON
      // pour les options, faire des OU entre les différentes options
      [new JsonEncoder(new JsonEncode([JsonEncode::OPTIONS => JSON_UNESCAPED_UNICODE]))]
    );
    // sérialisation jSON
    $json = $serializer->serialize($content, 'json');
    // headers
    $headers = array_merge($headers, ["content-type" => "application/json"]);
    // envoi réponse
    parent::sendResponse($statusCode, $json, $headers);
    // log
    if ($logger !== NULL) {
      $logger->write("réponse=$json\n");
    }
  }

}

Commentaires

• ligne 13 : la classe implémente l’interface [InterfaceResponse] ;
• ligne 13 : la classe étend la classe [ParentResponse]. Tous les types de [Response] étendent cette classe. C’est cette classe parent qui envoie la réponse au client (ligne 46). C’est parce que cet code était commun à tous les types de [Response] qu’il a été factorisé dans une classe parent ;
• lignes 33-40 : instanciation du sérialiseur [Symfony] qui va traduire la réponse du serveur [$content] en chaîne jSON (ligne 42) ;
• lignes 34-36 : le 1^er paramètre du constructeur de [Serializer] est un tableau. Dans celui-ci, on met une instance de la classe [ObjectNormalizer] nécessaire à la sérialisation d’objets. Ce cas se présente dans cette application avec une liste de simulations où chaque simulation est une instance de la classe [Simulation] ;
• ligne 39 : le second paramètre du constructeur de [Serializer] est également un tableau : on y met tous les encodeurs utilisés dans une sérialisation (XML, jSON, CSV…) ;
• ligne 39 : il n’y aura qu’un encodeur ici, de type [JsonEncoder]. Le constructeur sans paramètres aurait pu être suffisant. Ici, nous avons passé un paramètre [JsonEncode] au constructeur, uniquement pour passer des options d’encodage jSON ;
• ligne 39 : le paramètre du constructeur [JsonEncode] est un tableau d’options. Ici on utilise l’option [JSON_UNESCAPED_UNICODE] pour demander que les caractères UTF-8 de la chaîne jSON soient rendus nativement et non pas « échappés » ;
• ligne 42 : le corps de la réponse HTTP est sérialisé en jSON grâce au sérialiseur précédent ;
• ligne 44 : on ajoute l’entête HTTP qui dit au client qu’on va lui envoyer du jSON ;
• ligne 46 : on demande à la classe parent d’envoyer la réponse au client ;
• lignes 48-50 : on logue la réponse jSON ;

Le code de la classe parent [ParentResponse] est le suivant :

<?php

namespace Application;

// dépendances Symfony
use Symfony\Component\HttpFoundation\Response;

class ParentResponse {

  // int $statusCode : le code HTTP de statut de la réponse
  // string $content : le corps de la réponse à envoyer
  // selon les cas, c'est une chaîne jSON, XML, HTML
  // array $headers : les entêtes HTTP à ajouter à la réponse

  public function sendResponse(
    int $statusCode,
    string $content,
    array $headers): void {

    // préparation de la réponse texte du serveur
    $response = new Response();
    $response->setCharset("utf-8");
    // code de statut
    $response->setStatusCode($statusCode);
    // headers
    foreach ($headers as $text => $value) {
      $response->headers->set($text, $value);
    }
    // on envoie la réponse
    $response->setContent($content);
    $response->send();
  }
}

Commentaires

• lignes 10-13 : la signification des trois paramètres de la méthode [send] ;
• ligne 17 : on notera que le corps de la réponse est de type [string] et donc prêt à être envoyé (ligne 30) ;
• ligne 22 : la réponse aura des caractères UTF-8 ;
• ligne 24 : code de statut HTTP de la réponse ;
• lignes 26-28 : ajout des entêtes HTTP donnés par le code appelant ;
• lignes 30-31 : envoi de la réponse au client ;

Nous avons détaillé tout le cycle d’une réponse jSON. Nous ne reviendrons pas dessus dans la suite. Il faut simplement se rappeler la signature de l’interface [InterfaceResponse] :

interface InterfaceResponse {

  // Request $request : requête en cours de traitement
  // Session $session : la session de l'application web
  // array $config : la configuration de l'application
  // int statusCode : le code HTTP de statut de la réponse
  // array $content : la réponse du serveur
  // array $headers : les entêtes HTTP à ajouter à la réponse
  // Logger $logger : le logueur pour écrire des logs
  
  public function send(
    Request $request = NULL,
    Session $session = NULL,
    array $config,
    int $statusCode,
    array $content,
    array $headers,
    Logger $logger = NULL): void;
}

Le contrôleur principal [main.php] devra respecter cette signature à chaque fois qu’il demandera l’envoi de la réponse au client.

Nous modifions le fichier [config.json] de la façon suivante :

• en [1], nous indiquons que le fichier de logs est [Logs] qui est un dossier [2]. La création du fichier [Logs] devrait donc échouer ;

Nous créons une nouvelle requête [Postman] [3], appelée [erreur-133] :

• [2-4] : nous définissons la même requête que dans les deux tests précédents ;
• [5-7] : nous récupérons bien la réponse jSON attendue ;

Continuons l’étude du contrôleur principal [main.php] :

<?php

// respect strict des types déclarés des paramètres de foctions
declare (strict_types=1);

// espace de noms
namespace Application;

// dépendances Symfony
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpFoundation\Session\Session;

// gestion des erreurs par PHP
…

// création du fichier des logs
…

// 1er log
$logger->write("\n---nouvelle requête\n");
// requête courante
$request = Request::createFromGlobals();

// session
$session = new Session();
$session->start();
// liste d'erreurs
$erreurs = [];
$erreur = FALSE;
// on gère l'action demandée
if (!$request->query->has("action")) {
  $erreurs[] = "paramètre [action] manquant";
  $erreur = TRUE;
  $état = 101;
  $action = "";
} else {
  // on mémorise l'action
  $action = strtolower($request->query->get("action"));
}
// on logue l'action
$logger->write("action [$action] demandée\n");

// l'action existe-t-elle ?
if (!$erreur && !array_key_exists($action, $config["actions"])) {
  $erreurs[] = "action [$action] invalide";
  $erreur = TRUE;
  $état = 102;
}

// le type de session doit être connu avant de faire certaines actions
if (!$erreur && !$session->has("type") && $action !== "init-session") {
  $erreurs[] = "pas de session en cours. Commencer par action [init-session]";
  $erreur = TRUE;
  $état = 103;
}

// pour certaines actions on doit être authentifié
if (!$erreur && !$session->has("user") && $action !== "authentifier-utilisateur" && $action !== "init-session") {
  $erreurs[] = "action demandée par utilisateur non authentifié";
  $erreur = TRUE;
  $état = 104;
}

// erreurs ?
if ($erreurs) {
  // on prépare la réponse sans l'envoyer  
  $statusCode = Response::HTTP_BAD_REQUEST;
  $content = ["réponse" => $erreurs];
  $headers = [];
} else {
  // ---------------------------
  // on exécute l'action à l'aide de son contrôleur
  $controller = __NAMESPACE__ . $config["actions"][$action];
  $logger->write("contrôleur : $controller\n");
  list($statusCode, $état, $content, $headers) = (new $controller())->execute($config, $request, $session);
}

// --------------------- on envoie la réponse
// cas de l'erreur fatale HTTP_INTERNAL_SERVER_ERROR
// on envoie un mail à l'administrateur si on peut
if ($statusCode === Response::HTTP_INTERNAL_SERVER_ERROR && $config['adminMail'] != NULL) {
  $infosMail = $config['adminMail'];
  $infosMail['message'] = json_encode($content, JSON_UNESCAPED_UNICODE);
  $sendAdminMail = new SendAdminMail($infosMail, $logger);
  $sendAdminMail->send();
}
// la réponse dépend du type de la session
if ($session->has("type")) {
  // le type de session est dans la session
  $type = $session->get("type");
} else {
  // si pas de type dans session, alors par défaut ce sera une réponse en jSON
  $type = "json";
}
// on ajoute les clés [action, état] à la réponse du contrôleur
$content = ["action" => $action, "état" => $état] + $content;
// on instancie l'objet [Response] chargée d'envoyer la réponse au client
$response = __NAMESPACE__ . $config["types"][$type]["response"];
(new $response())->send($request, $session, $config, $statusCode, $content, $headers, $logger);

// la réponse a été envoyée - on libère les ressources
$logger->close();
exit;

Commentaires

• une fois que les premières vérifications ont été faites et qu’il sait qu’il peut travailler, le contrôleur principal s’intéresse à l’action qu’on lui a demandée : elle doit remplir certaines conditions ;
• ligne 21 : on logue le fait qu’on a une nouvelle requête. On ne pouvait pas le faire avant car on n’était pas sûr d’avoir un fichier de logs valide ;
• ligne 23 : on encapsule toutes les informations de la requête du client dans l’objet Symfony [Request] ;
• ligne 26 : on démarre une nouvelle session où on récupère la session existante si elle existe ;
• ligne 27 : la session est activée ;
• ligne 29 : un tableau de messages d’erreur ;
• ligne 30 : un booléen qui au fil des tests nous dit si on a rencontré ou pas une erreur ;
• ligne 32 : le paramètre [action] doit faire partie de l’URL sous la forme [main.php?action=uneAction]. Le paramètre [action] fait alors partie des paramètres [$request->query] ;
• lignes 33-36 : cas de l’absence du paramètre [action] dans l’URL. L’erreur est notée et un état [101] lui est attribué ;
• ligne 39 : si le paramètre [action] est présent dans l’URL, il est mémorisé ;
• ligne 42 : le type de l’action est logué ;
• lignes 45-49 : si le paramètre [action] est présent, il doit alors être valide. Toutes les actions autorisées sont définies dans le tableau associatif [$config["actions"]] ;
• lignes 46-48 : si l’action est invalide, l’erreur est notée et l’état [102] lui est attribué ;
• lignes 52-56 : on a une action valide. Elle doit encore remplir d’autres conditions. L’application web fournit trois types de réponse (jSON, XML, HTML). Ce type est fixé par l’action [init-session]. Cette action place le type de la session dans la clé [type] ;
• ligne 52 : en-dehors de l’action [init-session], tout autre action doit se dérouler avec une clé [type] dans la session ;
• lignes 53-55 : si ce n’est pas le cas, l’erreur est notée et l’état [103] lui est attribué ;
• lignes 58-63 : en-dehors des actions [init-session] et [authentifier-utilisateur], toutes les autres actions doivent se faire après authentification. Celle-ci se fait à l’aide de l’action [authentifier-utilisateur], qui si l’authentification réussit met une clé [user] dans la session ;
• ligne 59 : si l’action n’est ni [init-session] ni [authentifier-utilisateur] et que la clé [user] n’est pas dans la session, alors on a une erreur ;
• lignes 60-62 : on note l’erreur et lui attribue l’état [104] ;
• lignes 66-71 : on teste si le tableau [$erreurs] est non vide. Si c’est le cas, alors l’action demandée ou son contexte d’exécution sont erronés ;
• lignes 68-70 : on prépare la réponse à envoyer au client mais on ne l’envoie pas encore ;
• ligne 68 : code de statut HTTP ;
• ligne 69 : corps de la réponse ;
• ligne 70 : entêtes à ajouter à la réponse, aucun ici ;
• ligne 73 : on a une action valide. On va demander à son contrôleur (secondaire) de la traiter ;
• ligne 74 : on construit le nom de la classe du contrôleur à exécuter. [__NAMESPACE__] est l’espace de noms dans lequel on se trouve, ici [Application] (ligne 7) ;
• les noms des classes de contrôleur secondaire sont dans le fichier [config.json] :

"actions":
            {
                "init-session": "\\InitSessionController",
                "authentifier-utilisateur": "\\AuthentifierUtilisateurController",
                "calculer-impot": "\\CalculerImpotController",
                "lister-simulations": "\\ListerSimulationsController",
                "supprimer-simulation": "\\SupprimerSimulationController",
                "fin-session": "\\FinSessionController",
                "afficher-calcul-impot": "\\AfficherCalculImpotController"
            },

A chaque action correspond un contrôleur secondaire. Si l’action est [authentifier-utilisateur], la variable [$controller] de la ligne 74 aura donc la valeur [Application/AuthentifierUtilisateurController] ;

• ligne 75 : on logue le nom du contrôleur secondaire, pour vérification en cours de développement ;
• ligne 76 : le contrôleur secondaire est exécuté. Nous reviendrons sur les contrôleurs secondaires un peu plus loin ;
• ligne 76 : tous les contrôleurs secondaires rendent le même type de résultat qui est un tableau :
  • le 1^er élement du tableau [$statusCode] est le code de statut HTTP de la réponse à envoyer ;
  • le second élément [$état] est l’état de l’application après exécution du contrôleur ;
  • le troisième élément [$content] est un tableau associatif avec l’unique clé [réponse] qui est le corps de la réponse à envoyer au client ;
  • le quatrième élément [$headers] est un tableau d’entêtes HTTP à ajouter à la réponse envoyée au client ;
• ligne 79 : on arrive ici :
  • soit parce qu’il y a eu erreur (lignes 68-70) ;
  • soit après exécution d’un contrôleur (lignes 72-76) ;
  • dans les deux cas, les éléments [$statusCode, $état, $content, $headers] nécessaires à l’élaboration de la réponse au client sont connus ;
• lignes 82-87 : traitent le cas particulier du code de statut [500 Internal Server Error]. Si un contrôleur a mis ce code de statut, c’est que l’application ne peut pas fonctionner. C’est par exemple le cas du calcul de l’impôt si le SGBD utilisé n’a pas été lancé ou ne répond plus. On envoie alors un mail à l’administrateur de l’application pour l’avertir. Nous ne commenterons pas particulièrement ce code. L’utilisation de la classe [SendAdminMail] a déjà été présentée (paragraphe lienLa classe [SendAdminMail]) ;
• lignes 89-95 : on détermine le type [jSON, XML, HTML] de l’application web. Si l’action [init-session] a été exécutée avec succès, ce type est dans la session associé à la clé [type] (ligne 91). Si ce n’est pas le cas, alors on fixe arbitrairement un type pour la réponse, le type jSON (ligne 94) ;
• ligne 97 : [$content] est un tableau avec une unique clé [réponse] et une unique valeur, le corps de la réponse à envoyer au client. On lui ajoute les clés [action] et [état]. La clé [action] permettra de mieux suivre les logs du fichier [logs.txt]. La clé [état] aura deux rôles :
  • elle permettra aux clients jSON et XML de connaître l’état dans lequel l’action exécutée a mis l’application web ;
  • dans le cas d’une réponse HTML, elle permettra de choisir la vue HTML qu’il faut envoyer au navigateur client ;
• ligne 99 : on choisit le type de classe [Response] à exécuter pour envoyer la réponse au client ;

Nous avons déjà présenté la classe [JsonResponse] au paragraphe lien[main.php] – 2. Elle implémente l’interface [InterfaceResponse] et étend la classe [ParentResponse]. C’est le cas des deux autres classes [XmlResponse] et [HtmlResponse].

Les réponses sont rassemblées dans le dossier [Responses] :

Toutes ces classes implémentent l’interface [InterfaceResponse] présentée également au paragraphe lienLa couche [métier] :

<?php

namespace Application;

// dépendances Symfony
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Session\Session;

interface InterfaceResponse {

  // Request $request : requête en cours de traitement
  // Session $session : la session de l'application web
  // array $config : la configuration de l'application
  // int statusCode : le code HTTP de statut de la réponse
  // array $content : la réponse du serveur
  // array $headers : les entêtes HTTP à ajouter à la réponse
  // Logger $logger : le logueur pour écrire des logs
  
  public function send(
    Request $request = NULL,
    Session $session = NULL,
    array $config,
    int $statusCode,
    array $content,
    array $headers,
    Logger $logger = NULL): void;
}

Cette interface a une unique méthode [send] chargée d’envoyer la réponse au client. Cette méthode a les 7 paramètres décrits aux lignes 11-17. Toutes les classes et interfaces du dossier [Responses] sont dans l’espace de noms [Application] (ligne 3).

Revenons au code de [main.php] :

…
// on ajoute les clés [action, état] à la réponse du contrôleur
$content = ["action" => $action, "état" => $état] + $content;
// on instancie l'objet [Response] chargée d'envoyer la réponse au client
$response = __NAMESPACE__ . $config["types"][$type];
(new $response())->send($request, $session, $config, $statusCode, $content, $headers, $logger);

// la réponse a été envoyée - on libère les ressources
$logger->close();
exit;

• ligne 5 : on instancie la classe [Response] qui convient au type de l’application. Ces classes sont définies dans le fichier [config.json] de la façon suivante :
   

  Sélectionnez

  1.
  2.
  3.
  4.
  5.
  

  "types": {
          "json": "\\JsonResponse",
          "html": "\\HtmlResponse",
          "xml": "\\XmlResponse"
      },
  

• ligne 5 : le nom de la classe est préfixée par son espace de noms ;
• ligne 6 : la classe [Response] est instanciée et sa méthode [send] appelée avec les 7 paramètres qu’elle attend. Ces paramètres sont ceux de l’interface [InterfaceResponse] que tous les classes de réponse implémentent. Cela envoie la réponse au client ;
• ligne 9 : on ferme le fichier de logs ;
• ligne 10 : le contrôleur principal a terminé son travail ;

On va tester divers cas d’erreur du paramètre [action] de l’URL.

• en [1] :
  • [erreur-101] : cas du paramètre [action] manquant dans l’URL ;
  • [erreur-102] : cas du paramètre [action] présent dans l’URL mais non reconnu ;
  • [erreur-103] : cas du paramètre [action] présent dans l’URL, reconnu mais sans que le type de réponse attendue [json, xml, html] ait été défini ;

Chaque requête est exécutée. Nous présentons directement les résultats obtenus :

Ci-dessus :

• en [2-4], une requête sans le paramètre [action] dans l’URL [4] ;
• en [5-7], le résultat jSON ;

Ci-dessus :

• en [5-9], une requête avec un paramètre [action] invalide ;
• en [10-13], la réponse jSON ;

Ci-dessus :

• en [14-19], une action reconnue mais le type (json, xml, html) n’a pas encore été précisé ;
• en [20-23], la réponse jSON du serveur ;

L’action [init-session] est traitée par le contrôleur [InitSessionController] suivant :

<?php

namespace Application;

// dépendances Symfony
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpFoundation\Session\Session;

class InitSessionController implements InterfaceController {

  // $config est la configuration de l'application
  // traitement d'une requête Request
  // utile la session Session et peut la modifier
  // $infos sont des informations supplémentaires propres à chaque contrôleur
  
  // rend un tableau [$statusCode, $état, $content, $headers]
  public function execute(
    array $config,
    Request $request,
    Session $session,
    array $infos = NULL): array {

    // on doit avoir un GET et un unique paramètre autre que [action]
    $method = strtolower($request->getMethod());
    $erreur = $method !== "get" || $request->query->count() != 2;
    if ($erreur) {
      $état = 701;
      $message = "méthode GET exigée avec paramètres [action, type] dans l'URL";
      return [Response::HTTP_BAD_REQUEST, $état, ["réponse" => $message], []];
    }
    // on récupère le paramètres du GET
    $erreur = FALSE;
    // type
    if (!$request->query->has("type")) {
      $erreur = TRUE;
      $état = 702;
      $message = "paramètre [type] manquant";
    } else {
      $type = strtolower($request->query->get("type"));
    }
    // vérification du type
    if (!$erreur && !array_key_exists($type, $config["types"])) {
      $erreur = TRUE;
      $état = 703;
      $message = "paramètre type [$type] invalide";
    }
    // erreur ?
    if ($erreur) {
      return [Response::HTTP_BAD_REQUEST, $état, ["réponse" => $message], []];
    }
    // on met le type de session dans la session
    $session->set("type", $type);
    // message de réussite
    $message = "session démarrée avec type [$type]";
    $état = 700;
    return [Response::HTTP_OK, $état, ["réponse" => $message], []];
  }

}

Commentaires

• on attend une requête [GET main.php?action=init-session&type=xxx]
• lignes 25-26 : on vérifie que la requête est une requête GET avec deux paramètres dans l’URL ;
• lignes 27-31 : si ce n’est pas le cas, on note l’erreur et on envoie un résultat [$statusCode, $état, $content, $headers] au contrôleur principal ;
• lignes 35-39 : on vérifie que le paramètre [type] est bien présent dans l’URL. Si ce n’est pas le cas, on note l’erreur ;
• ligne 40 : on note le type de la session ;
• lignes 43-47 : on vérifie que le type de la session est l’un des termes (json, xml, html). Si ce n’est pas le cas, on note l’erreur ;
• lignes 49-51 : s’il y a eu erreur, on envoie un résultat [$statusCode, $état, $content, $headers] au contrôleur principal ;
• ligne 53 : le type de la session est mis dans la session de l’application web ;
• lignes 55-57 : le contrôleur a fini son travail. On envoie un résultat [$statusCode, $état, $content, $headers] de succès au contrôleur principal ;

Rappelons ce que fait le contrôleur principal de la réponse des contrôleurs secondaires :

// erreurs ?
if ($erreurs) {
  // on prépare la réponse sans l'envoyer  
  $statusCode = Response::HTTP_BAD_REQUEST;
  $content = ["réponse" => $erreurs];
  $headers = [];
} else {
  // ---------------------------
  // on exécute l'action à l'aide de son contrôleur
  $controller = __NAMESPACE__ . $config["actions"][$action];
  $logger->write("contrôleur : $controller\n");
  list($statusCode, $état, $content, $headers) = (new $controller())->execute($config, $request, $session);
}

// --------------------- on envoie la réponse
// cas de l'erreur fatale HTTP_INTERNAL_SERVER_ERROR
// on envoie un mail à l'administrateur si on peut
if ($statusCode === Response::HTTP_INTERNAL_SERVER_ERROR && $config['adminMail'] != NULL) {
  $infosMail = $config['adminMail'];
  $infosMail['message'] = json_encode($content, JSON_UNESCAPED_UNICODE);
  $sendAdminMail = new SendAdminMail($infosMail, $logger);
  $sendAdminMail->send();
}
// la réponse dépend du type de la session
if ($session->has("type")) {
  // le type de session est dans la session
  $type = $session->get("type");
} else {
  // si pas de type dans session, alors par défaut ce sera une réponse en jSON
  $type = "json";
}
// on ajoute les clés [action, état] à la réponse du contrôleur
$content = ["action" => $action, "état" => $état] + $content;
// on instancie l'objet [Response] chargée d'envoyer la réponse au client
$response = __NAMESPACE__ . $config["types"][$type]["response"];
(new $response())->send($request, $session, $config, $statusCode, $content, $headers, $logger);

// la réponse a été envoyée - on libère les ressources
$logger->close();
exit;

• ligne 12 : le contrôleur principal récupère le résultat du contrôleur secondaire ;
• lignes 35-36 : après quelques vérifications, il envoie la réponse en instanciant l’une des classes [JsonResponse, XmlResponse, HtmlResponse] selon le type (json, xml, html) de la session en cours ;

Dans la suite, nous ferons des tests [Postman] dans le cadre d’une session de simulations avec le type [json]. Le fonctionnement de la classe [JsonResponse] a été présenté au paragraphe lienLa couche [métier].

Ci-dessus :

• en [2], trois nouveaux tests ;
• en [3-7], l’action [init-session] avec le paramètre [type] manquant ;
• en [8-11], la réponse jSON du serveur ;

Ci-dessus :

• en [1-7], l’action [init-session] avec un paramètre [type] incorrect ;
• en [8-11], la réponse jSON du serveur ;

Ci-dessus :

• en [1-8], l’action [init-session] avec le type jSON ;
• en [9-12], la réponse jSON du serveur ;

L’action [authentifier-utilisateur] est exécutée par le contrôleur [AuthentifierUtilisateurController] suivant :

<?php

namespace Application;

// dépendances Symfony
use \Symfony\Component\HttpFoundation\Response;
use \Symfony\Component\HttpFoundation\Request;
use \Symfony\Component\HttpFoundation\Session\Session;

class AuthentifierUtilisateurController implements InterfaceController {

  // $config est la configuration de l'application
  // traitement d'une requête Request
  // utile la session Session et peut la modifier
  // $infos sont des informations supplémentaires propres à chaque contrôleur
  // rend un tableau [$statusCode, $état, $content, $headers]
  public function execute(
    array $config,
    Request $request,
    Session $session,
    array $infos = NULL): array {

    // on doit avoir un POST et un unique paramètre GET
    $method = strtolower($request->getMethod());
    $erreur = $method !== "post" || $request->query->count() != 1;
    if ($erreur) {
      $état = 201;
      $message = "méthode POST requise, paramètre [action] dans l'URL, paramètres postés [user,password]";
      // on rend le résultat au contrôleur principal
      return [Response::HTTP_BAD_REQUEST, $état, ["réponse" => $message], []];
    }
    // on récupère les paramètres du POST
    $erreurs = [];
    // user
    $état = 210;
    if (!$request->request->has("user")) {
      $état += 2;
      $erreurs[] = "paramètre [user] manquant";
    } else {
      $user = $request->request->get("user");
    }
    // password
    if (!$request->request->has("password")) {
      $état += 4;
      $erreurs[] = "paramètre [password] manquant";
    } else {
      $password = trim($request->request->get("password"));
    }
    // erreur ?
    if ($erreurs) {
      // on rend le résultat au contrôleur principal
      return [Response::HTTP_BAD_REQUEST, $état, ["réponse" => $erreurs], []];
    }
    // vérification des identifiants de l'utilisateur
    // l'utilisateur existe-t-il ?
    $users = $config["users"];
    $i = 0;
    $trouvé = FALSE;
    while (!$trouvé && $i < count($users)) {
      $trouvé = ($user === $users[$i]["login"] && $users[$i]["passwd"] === $password);
      $i++;
    }
    // trouvé ?
    if (!$trouvé) {
      // message d'erreur
      $message = "Echec de l'authentification [$user, $password]";
      $état = 221;
      // on rend le résultat au contrôleur principal
      return [Response::HTTP_UNAUTHORIZED, $état, ["réponse" => $message], []];
    } else {
      // on note dans la session qu'on a authentifié l'utilisateur
      $session->set("user", TRUE);
      // message de réussite
      $message = "Authentification réussie [$user, $password]";
      $état = 200;
      // on rend le résultat au contrôleur principal
      return [Response::HTTP_OK, $état, ["réponse" => $message], []];
    }
  }

}

Commentaires

• on attend une requête [POST main.php?action=authentifier-utilisateur] avec deux paramètres postés [user, password] ;
• lignes 24-25 : on vérifie qu’on a une requête POST avec un unique paramètre dans l’URL ;
• lignes 26-31 : si erreur il y a, on la note et on rend un résultat [$statusCode, $état, $content, $headers] au contrôleur principal ;
• lignes 36-39 : on vérifie la présence du paramètre [user] dans les valeurs postées. S’il n’est pas présent, on note l’erreur ;
• lignes 43-45 : on vérifie la présence du paramètre [password] dans les valeurs postées. S’il n’est pas présent, on note l’erreur ;
• lignes 50-53 : si l’une des valeurs postées est manquante, un résultat [$statusCode, $état, $content, $headers] est rendu au contrôleur principal ;
• lignes 56-62 : on vérifie que le couple [$user,$password] récupéré est présent dans le tableau [$config[‘users’]] du fichier de configuration ;
• lignes 64-69 : si ce n’est pas le cas, l’erreur est notée. Le code de statut HTTP est mis à [Response::HTTP_UNAUTHORIZED] et le résultat [$statusCode, $état, $content, $headers] rendu au contrôleur principal ;
• ligne 72 : l’authentification a réussi. On le note dans la session en plaçant dans celle-ci la clé [user]. C’est la présence de cette clé qui indique une authentification réussie ;
• lignes 73-77 : on rend un résultat [$statusCode, $état, $content, $headers] de réussite au contrôleur principal ;

Nous procédons aux tests [Postman] du contrôleur [AuthentifierUtilisateurController] en mode jSON ;

Ci-dessus :

• en [1-6], l’action [authentifier-utilisateur] avec un GET [2], alors qu’il faut un POST ;
• en [7-10], la réponse jSON du serveur ;

Remplaçons le GET par un POST [2] sans mettre de paramètres dans le corps de la réponse [7] :

Ci-dessus :

• en [1-7], le POST sans paramètres postés en [7] ;
• en [8-11], la réponse jSON du serveur ;

Ajoutons maintenant un paramètre [password] dans le corps (body) [4] de la requête :

Ci-dessus :

• en [1-6], un requête POST [2] avec un paramètre [password] posté [4-6]. Les paramètres postés doivent être ajoutés dans le corps (body) de la requête [4]. Il y a plusieurs façons de poster des valeurs au serveur. Nous choisissons la méthode [x-www-form-urlencoded] [5] ;
• en [8-10], la réponse jSON du serveur ;

Maintenant définissons le paramètre [user] sans le paramètre [password] :

Ci-dessus :

• en [1-7], une requête POST sans le paramètre [password] [4-7] ;
• en [8-11], la réponse jSON du serveur ;

Maintenant définissons les deux paramètres postés [user, password] mais avec des valeurs qui font que l’authentification échoue :

Ci-dessus :

• en [1-9], une requête POST avec des paramètres postés [user, password] incorrects ;
• en [10-13], la réponse jSON du serveur. On remarquera le code de statut [401 Unauthorized] [10] de la réponse ;

Maintenant une requête POST avec des identifiants valides :

Ci-dessus :

• en [1-9], la requête POST [2] avec des identifiants valides [6-9] ;
• en [10-13], la réponse jSON du serveur. On remarquera le code de statut HTTP [200 OK] en [10] ;

L’action [calculer-impot] est traitée par le contrôleur [CalculerImpotController] suivant :

<?php

namespace Application;

// dépendances Symfony
use \Symfony\Component\HttpFoundation\Response;
use \Symfony\Component\HttpFoundation\Request;
use \Symfony\Component\HttpFoundation\Session\Session;
// alias de la couche [dao]
use \Application\ServerDaoWithSession as ServerDaoWithRedis;

class CalculerImpotController implements InterfaceController {

  // $config est la configuration de l'application
  // traitement d'une requête Request
  // utile la session Session et peut la modifier
  // $infos sont des informations supplémentaires propres à chaque contrôleur
  // rend un tableau [$statusCode, $état, $content, $headers]
  public function execute(
    array $config,
    Request $request,
    Session $session,
    array $infos = NULL): array {

    // on doit avoir un paramètre GET et trois paramètres POST
    $method = strtolower($request->getMethod());
    $erreur = $method !== "post" || $request->query->count() != 1;
    if ($erreur) {
      // on note l'erreur
      $message = "il faut utiliser la méthode [post] avec [action] dans l'URL et les paramètres postés [marié, enfants, salaire]";
      $état = 301;
      // retour résultat au contrôleur principal
      return [Response::HTTP_BAD_REQUEST, $état, ["réponse" => $message], []];
    }
    // on récupère les paramètres du POST
    $erreurs = [];
    $état = 310;
    // statut marital
    if (!$request->request->has("marié")) {
      $état += 2;
      $erreurs[] = "paramètre [marié] manquant";
    } else {
      $marié = trim(strtolower($request->request->get("marié")));
      $erreur = $marié !== "oui" && $marié !== "non";
      if ($erreur) {
        $état += 4;
        $erreurs[] = "valeur [$marié] invalide pour le paramètre [marié]";
      }
    }
    // on récupère le nombre d'enfants
    if (!$request->request->has("enfants")) {
      $état += 8;
      $erreurs[] = "paramètre [enfants] manquant";
    } else {
      $enfants = trim($request->request->get("enfants"));
      $erreur = !preg_match("/^\d+$/", $enfants);
      if ($erreur) {
        $état += 9;
        $erreurs[] = "valeur [$enfants] invalide pour le paramètre [enfants]";
      }
    }
    // on récupère le salaire annuel
    if (!$request->request->has("salaire")) {
      $erreurs[] = "paramètre [salaire] manquant";
      $état += 16;
    } else {
      $salaire = trim($request->request->get("salaire"));
      $erreur = !preg_match("/^\d+$/", $salaire);
      if ($erreur) {
        $état += 17;
        $erreurs[] = "valeur [$salaire] invalide pour le paramètre [salaire]";
      }
    }
    // erreur ?
    if ($erreurs) {
      // retour résultat au contrôleur principal
      return [Response::HTTP_BAD_REQUEST, $état, ["réponse" => $erreurs], []];
    }

    // on a tout ce qu'il faut pour travailler
    // Redis
    \Predis\Autoloader::register();
    try {
      // client [predis]
      $redis = new \Predis\Client();
      // on se connecte au serveur pour voir s'il est là
      $redis->connect();
    } catch (\Predis\Connection\ConnectionException $ex) {
      // ça s'est mal passé
      // retour résultat avec erreur au contrôleur principal
      $état = 350;
      return [Response::HTTP_INTERNAL_SERVER_ERROR, $état,
        ["réponse" => "[redis], " . utf8_encode($ex->getMessage())], []];
    }

    // on a des paramètres valides
    // création de la couche [dao]
    if (!$redis->get("taxAdminData")) {
      try {
        // on va chercher les données fiscales en base
        $dao = new ServerDaoWithRedis($config["databaseFilename"], NULL);
        // on met dans redis les données récupérées
        $redis->set("taxAdminData", $dao->getTaxAdminData());
      } catch (\RuntimeException $ex) {
        // ça s'est mal passé
        // retour résultat avec erreur au contrôleur principal
        $état = 340;
        return [Response::HTTP_INTERNAL_SERVER_ERROR, $état,
          ["réponse" => utf8_encode($ex->getMessage())], []];
      }
    } else {
      // les données fiscales sont prises dans la mémoire de portée [application]
      $arrayOfAttributes = \json_decode($redis->get("taxAdminData"), true);
      $taxAdminData = (new TaxAdminData())->setFromArrayOfAttributes($arrayOfAttributes);
      // isntanciation de la couche [dao]
      $dao = new ServerDaoWithRedis(NULL, $taxAdminData);
    }
    // création de la couche [métier]
    $métier = new ServerMetier($dao);

    // on a tout ce qu'il faut pour travailler - calcul de l'impôt
    $résultat = $métier->calculerImpot($marié, (int) $enfants, (int) $salaire);
    // on ajoute dans la session la simulation qui vient d'être faite
    $simulation = new Simulation();
    $résultat = ["marié" => $marié, "enfants" => $enfants, "salaire" => $salaire] + $résultat;
    $simulation->setFromArrayOfAttributes($résultat);
    // existe-t-il une liste de simulations en session ?
    if (!$session->has("simulations")) {
      $simulations = [];
    } else {
      $simulations = $session->get("simulations");
    }
    // ajout de la simulation à la liste de simulations
    $simulations[] = $simulation;
    // on remet les simulations en session
    $session->set("simulations", $simulations);
    // retour résultat au contrôleur principal
    $état = 300;
    return [Response::HTTP_OK, $état, ["réponse" => $résultat], []];
  }

}

Commentaires

• la requête attendue est [POST main.php?action=calculer-impot] avec trois paramètres postés [marié, enfants, salaire] :
  • [marié] doit avoir sa valeur dans [oui, non] ;
  • [enfants, salaire] doivent être des entiers positifs ou nuls ;
• lignes 26-27 : on vérifie qu’on a bien un POST avec un unique paramètre dans l’URL ;
• lignes 28-34 : si ce n’est pas le cas, un résultat d’erreur est envoyé au contrôleur principal ;
• ligne 36 : on va cumuler les messages d’erreur dans le tableau [$erreurs] ;
• lignes 39-41 : on vérifie la présence du paramètre [marié]. S’il n’est pas présent, l’erreur est notée ;
• lignes 43-49 : on vérifie que [marié] a sa valeur dans [oui, non]. Si ce n’est pas le cas, l’erreur est notée ;
• lignes 51-54 : on vérifie la présence du paramètre [enfants]. S’il n’est pas présent, l’erreur est notée ;
• lignes 55-61 : on vérifie que la valeur du paramètre [enfants] est un nombre positif ou nul. Si ce n’est pas le cas, l’erreur est notée ;
• lignes 63-66 : on vérifie la présence du paramètre [salaire]. S’il n’est pas présent, l’erreur est notée ;
• lignes 67-72 : on vérifie que la valeur du paramètre [salaire] est un nombre positif ou nul. Si ce n’est pas le cas, l’erreur est notée ;
• lignes 75-78 : si le tableau [$erreurs] n’est pas vide, c’est qu’il y a eu des erreurs. On met le tableau des erreurs dans la réponse et on rend le résultat au contrôleur principal ;
• ligne 80 : on a des paramètres valides. On peut calculer l’impôt. Il faut pour cela construire les couches [dao] et [métier] qui savent faire ce calcul ;
• lignes 82-94 : on crée un client [Redis] ;
• lignes 88-94 : si on n’a pas pu se connecter au serveur [Redis], on envoie un code [500 Internal Server Error] au client ;
• ligne 98 : on regarde si le serveur [Redis] a la clé [taxAdminData]. Cette clé représente les données de l’administration fiscale. Si la clé n’est pas présente, alors les données fiscales doivent être cherchées dans la base de données ;
• ligne 101 : construction de la couche [dao] lorsque les données fiscales doivent être prises en base. La classe [ServerDaoWithRedis] a été décrite au paragraphe lienCode du serveur ;
• ligne 103 : les données récupérées en base sont mises en mémoire [Redis] avec la clé [taxAdminData] ;
• lignes 104-110 : si la recherche en base s’est mal passée, on note l’erreur renvoyée par la couche [dao] et on l’intègre au résultat renvoyé au contrôleur principal ;
• ligne 109 : le message d’erreur renvoyé par la couche [PDO] est codé en [iso-8859-1]. On le code en [utf-8] ;
• lignes 111-117 : si la clé [taxAdminData] existe dans la mémoire [Redis], alors les données fiscales sont passées directement au constructeur de la couche [dao] ;
• ligne 119 : la couche [métier] est créée. La classe [ServerMetier] a été décrite au paragraphe lienLa couche [métier] ;
• lignes 124-126 : avec le montant de l’impôt calculé, un objet [Simulation] est créé. La classe [Simulation] encapsule les données d’une simulation et a été décrite au paragraphe lienLes entités de l’application ;
• lignes 128-132 : la simulation qui vient d’être construite doit être ajoutée à la liste des simulations déjà calculées. Cette liste se trouve en session sauf si aucune simulation n’a encore été faite ;
• ligne 133-136 : la simulation est ajoutée à la liste des simulations et celle-ci est remise en session ;
• lignes 137-139 : on rend le résultat au contrôleur principal ;

Nous procédons aux tests [Postman] du contrôleur [CalculerImpotController] en mode jSON ;

Ci-dessus :

• en [1-7] on fait une requête [GET] au lieu de [POST] ;
• en [8-11], la réponse jSON du serveur ;

Maintenant, utilisons une méthode [POST], avec ou sans paramètres postés ainsi qu’avec des paramètres postés invalides :

Ci-dessus :

• on fait une requête [POST] [2] avec des paramètres postés [6-11] [marié, enfants, salaire] invalides. On peut ne pas poster l’un de ces paramètres en décochant sa case dans [16]. Cela vous permettra de tester différents cas de figure. Sur la copie d’écran ci-dessus, les trois paramètres sont présents et tous invalides ;
• en [12-15], la réponse jSON du serveur ;

Maintenant décochons deux des trois paramètres postés :

Ci-dessus,

• en [5-8], seul le paramètre [salaire] est posté et de plus il est invalide ;
• en [9-11], le résultat jSON du serveur ;

Maintenant faisons un calcul d’impôt avec des paramètres valides :

Ci-dessus :

• en [1118], une demande avec des paramètres valides [6-8] ;
• en [12-14], la réponse jSON du serveur ;

L’action [lister-simulations] est traitée par le contrôleur secondaire [ListerSimulationsController] suivant :

<?php

namespace Application;

// dépendances Symfony
use \Symfony\Component\HttpFoundation\Response;
use \Symfony\Component\HttpFoundation\Request;
use \Symfony\Component\HttpFoundation\Session\Session;

class ListerSimulationsController {

  // $config est la configuration de l'application
  // traitement d'une requête Request
  // utile la session Session et peut la modifier
  // $infos sont des informations supplémentaires propres à chaque contrôleur
  // rend un tableau [$statusCode, $état, $content, $headers]
  public function execute(
    array $config,
    Request $request,
    Session $session,
    array $infos = NULL): array {

    // on doit avoir un unique paramètre GET
    $method = strtolower($request->getMethod());
    $erreur = $method !== "get" || $request->query->count() != 1;
    if ($erreur) {
      $état = 501;
      $message = "GET requis, avec l'unique paramètre [action] dans l'URL";
      // on rend un résultat avec erreur au contrôleur principal
      return [Response::HTTP_BAD_REQUEST, $état, ["réponse" => $message], []];
    }
    // on récupère la liste des simulations dans la session
    if (!$session->has("simulations")) {
      $simulations = [];
    } else {
      $simulations = $session->get("simulations");
    }
    // on rend un résultat avec sucès au contrôleur principal
    $état = 500;
    return [Response::HTTP_OK, $état, ["réponse" => $simulations], []];
  }

}

Commentaires

• requête [GET main.php?action=lister-simulations] ;
• lignes 24-25 : on vérifie qu’on a une requête GET avec un unique paramètre ;
• lignes 26-31 : si ce n’est pas le cas, un résultat avec erreur est rendu au contrôleur principal ;
• lignes 33-37 : on récupère la liste des simulations dans la session si elle s’y trouve (ligne 36), sinon cette liste est vide (ligne 34) ;
• lignes 39-40 : on rend la liste des simulations au contrôleur principal ;

Nous allons créer deux tests, un d’erreur et un réussi.

Ci-dessus :

• en [1-8], on fait une requête [GET] avec un paramètre [param1] en trop dans l’URL [3, 7-8] ;
• en [9-12], la réponse jSON du serveur ;

Maintenant faisons une requête valide :

Ci-dessus :

• en [1-5], une requête valide ;

Le résultat de la requête est le suivant :

• en [3-6], la réponse jSON du serveur. Avant ce test, le test [Postman] [calculer-impot-300] avait été exécuté plusieurs fois pour créer des simulations dans la session web du serveur ;

L’action [supprimer-simulation] est traitée par le contrôleur secondaire [SupprimerSessionController] suivant :

<?php

namespace Application;

// dépendances Symfony
use \Symfony\Component\HttpFoundation\Response;
use \Symfony\Component\HttpFoundation\Request;
use \Symfony\Component\HttpFoundation\Session\Session;

class SupprimerSimulationController {

  /// $config est la configuration de l'application
  // traitement d'une requête Request
  // utile la session Session et peut la modifier
  // $infos sont des informations supplémentaires propres à chaque contrôleur
  // rend un tableau [$statusCode, $état, $content, $headers]
  public function execute(
    array $config,
    Request $request,
    Session $session,
    array $infos = NULL): array {

    // on doit avoir deux paramètres GET
    $method = strtolower($request->getMethod());
    $erreur = $method !== "get" || $request->query->count() != 2;
    $état = 600;
    if ($erreur) {
      $état += 2;
      $message = "GET requis, avec les paramètres [action, numéro]";
    }
    // le paramètre [numéro] doit exister
    if (!$erreur) {
      $état += 4;
      $erreur = !$request->query->has("numéro");
      if ($erreur) {
        $message = "paramètre [numéro] manquant";
      }
    }
    // le paramètre [numéro] doit être valide
    if (!$erreur) {
      $état += 8;
      $numéro = $request->query->get("numéro");
      $erreur = !preg_match("/^\d+$/", $numéro);
      if ($erreur) {
        $message = "paramètre [$numéro] invalide";
      }
    }
    // le paramètre [numéro] doit être dans l'intervalle [0,n-1]
    // si n est le nombre de simulations
    if (!$erreur) {
      $numéro = (int) $numéro;
      $erreur = !$session->has("simulations");
      if (!$erreur) {
        $simulations = $session->get("simulations");
        $erreur = $numéro < 0 || $numéro >= count($simulations);
      }
      if ($erreur) {
        $état += 16;
        $message = "la simulation n° [$numéro] n'existe pas";
      }
    }
    // erreur ?
    if ($erreur) {
      // on rend le résultat au contrôleur principal
      return [Response::HTTP_BAD_REQUEST, $état, ["réponse" => $message], []];
    }
    // on supprime la simulation $numéro
    unset($simulations[$numéro]);
    $simulations = array_values($simulations);
    // on remet les simulations dans la session
    $session->set("simulations", $simulations);
    // on rend la liste des simulations au client
    $état = 600;
    return [Response::HTTP_OK, $état, ["réponse" => $simulations], []];
  }

}

Commentaires

• requête [GET main.php?action=supprimer-simulation&numéro=x] ;
• lignes 24-30 : on vérifie qu’on a une requête GET avec deux paramètres ;
• lignes 32-38 : on vérifie que le paramètre [numéro] existe dans les paramètres de l’URL ;
• lignes 40-47 : on vérifie que la valeur du paramètre [numéro] est syntaxiquement correcte ;
• lignes 50-61 : on vérifie que la simulation n° [numéro] existe bien. Il y a deux cas d’erreur :
  • la liste de simulations ne peut être trouvée dans la session (ligne 52) ;
  • le n° [numéro] de la simulation à supprimer n’existe pas dans la liste des simulations ;
• lignes 63-66 : en cas d’erreur, un résultat avec erreur est rendu au contrôleur principal ;
• ligne 68 : la simulation n° [numéro] est supprimée ;
• ligne 69 : l’opération [unset] ne change pas les index [0, n-1] de la liste. Pour les mettre à jour, on demande les valeurs du tableau [$simulations] pour éliminer la simulation manquante ;
• ligne 71 : on remet le nouveau tableau des simulations dans la session ;
• lignes 73-74 : on rend au contrôleur principal la nouvelle liste des simulations ;

Nous allons faire des tests d’erreur et de succès :

Ci-dessus :

• en [1-6], une requête GET sans le paramètre [numéro] ;
• en [7-10], la réponse jSON du serveur ;

Maintenant une requête avec un n° syntaxiquement incorrect :

Ci-dessus :

• en [1-5], une requête GET avec un paramtre [numéro] invalide [3, 5] ;
• en [6-9], la réponse jSON du serveur ;

Maintenant une requête avec un n° de simulation qui n’existe pas :

Ci-dessus :

• en [1-5], une requête avec un n° de simulation égal à 100 qui n’existe pas dans la liste des simulations ;
• en [6-9], la réponse jSON du serveur ;

Maintenant, nous allons supprimer la simulation n° 0 de la liste, donc la première simulation. Tout d’abord redemandons cette liste avec la requête [lister-simulations-500] :

• en [1], il y a actuellement 2 simulations ;

On supprime la 1^re simulation (numéro 0) :

Ci-dessus :

• en [1-5], on supprime la simulation n° 0 [5] ;
• en [6-9], la réponse jSON du serveur. On voit que la simulation n° 0 a été supprimée ;

Répétons cette opération :

Ci-dessus :

• en [1], il ne reste plus de simulations dans la session web du serveur ;

L’action [fin-session] est traitée par le contrôleur secondaire [FinSessionController] suivant :

<?php

namespace Application;

// dépendances Symfony
use \Symfony\Component\HttpFoundation\Response;
use \Symfony\Component\HttpFoundation\Request;
use \Symfony\Component\HttpFoundation\Session\Session;

class FinSessionController implements InterfaceController {

  // $config est la configuration de l'application
  // traitement d'une requête Request
  // utile la session Session et peut la modifier
  // $infos sont des informations supplémentaires propres à chaque contrôleur
  // rend un tableau [$statusCode, $état, $content, $headers]

  public function execute(
    array $config,
    Request $request,
    Session $session,
    array $infos = NULL): array {

    // on doit avoir un unique paramètre GET
    $method = strtolower($request->getMethod());
    $erreur = $method !== "get" || $request->query->count() != 1;
    // erreur ?
    if ($erreur) {
      $état = 401;
      // résultat au contrôleur principal
      $message = "GET requis avec le seul paramètre [action] dans l'URL";
      return [Response::HTTP_BAD_REQUEST, $état, ["réponse" => $message], []];
    }

    // on mémorise le type de session
    $type = $session->get("type");
    // on invalide la session courante
    $session->invalidate();
    // on remet le type dans la nouvelle session
    $session->set("type", $type);
    // envoi de la réponse
    $état = 400;
    // résultat au contrôleur principal
    $content = ["réponse" => "session supprimée"];
    return [Response::HTTP_OK, $état, $content, []];
  }

}

Commentaires

• requête [GET main.php?action=fin-session] ;
• lignes 25-33 : on vérifie que l’action est un GET avec l’unique paramètre [fin-action] ;
• ligne 38 : on invalide la session courante. Cela supprime les données enregistrées dans celle-ci et une nouvelle session est démarrée ;
• ligne 36 : avant la fin de la session, on mémorise le type [json, xml, html] de celle-ci ;
• ligne 40 : le type de la session précédente est replacé dans la nouvelle session. Finalement on repart avec une nouvelle session ayant l’uniqué clé [type] ;
• lignes 44-45 : on rend le résultat au contrôleur principal ;

Nous allons faire un test d’erreur et un test de réussite :

Ci-dessus :

• en [1-5], on demande la fin de session [5] avec un POST [2] au lieu du GET attendu ;
• en [6-9], la réponse jSON du serveur ;

Maintenant un exemple de réussite. Regardons tout d’abord le cookie de session échangé entre le client [Postman] et le serveur lors du dernier test réalisé :

Ci-dessus :

• en [3], le cookie de session envoyé par le client [Postman] au serveur ;

Regardons maintenant les entêtes HTTP envoyés par le serveur dans sa réponse :

Ci-dessus :

• en [3-4], le cookie de session n’est pas dans la réponse du serveur. C’est normal. Celui-ci ne l’envoie qu’une fois : au début d’une nouvelles session web ;

Maintenant exécutons une action [fin-session] valide :

Ci-dessus :

• en [1-3], une action [fin-session] valide ;
• en [4-7], la réponse jSON du serveur ;

Regardons les entêtes HTTP envoyés dans la réponse du serveur :

• en [3], le serveur envoie l’entête [Set-Cookie] montrant par là qu’une nouvelle session web démarre ;

Revenons sur l’architecture générale de l’application :

Nous allons présenter les types de réponse possibles [3a]. Celles-ci sont rassemblées dans le dossier [Responses] du projet :

Nous avons déjà présenté la classe [JsonResponse] au paragraphe lien[main.php] – 2. Elle implémente l’interface [InterfaceResponse] et étend la classe [ParentResponse]. C’est le cas des deux autres classes [XmlResponse] et [HtmlResponse].

Rappelons la définition de l’interface [InterfaceResponse] :

<?php

namespace Application;

// dépendances Symfony
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Session\Session;

interface InterfaceResponse {

  // Request $request : requête en cours de traitement
  // Session $session : la session de l'application web
  // array $config : la configuration de l'application
  // int statusCode : le code HTTP de statut de la réponse
  // array $content : la réponse du serveur
  // array $headers : les entêtes HTTP à ajouter à la réponse
  // Logger $logger : le logueur pour écrire des logs
  
  public function send(
    Request $request = NULL,
    Session $session = NULL,
    array $config,
    int $statusCode,
    array $content,
    array $headers,
    Logger $logger = NULL): void;
}

• lignes 19-27 : l’interface [InterfaceResponse] a une unique méthode [send] pour envoyer la réponse au client ;
• lignes 11-17 : la signification des différents paramètres de la méthode [send] ;
• lignes 23-25 : les paramètres [$statusCode, $content, $headers] sont la réponse standard des contrôleurs secondaires de l’application. Cependant la réponse peut avoir besoin d’autres informations. Aussi lui donne-t-on les trois premiers paramètres (lignes 20-22) qui lui donnent accès à la totalité des informations concernant la requête, la session, la configuration ;
• ligne 26 : la réponse a besoin du [Logger] car elle va loguer la réponse envoyée au client ;

Rappelons maintenant le code de la classe [ParentResponse], classe parent des trois types de réponse qui factorise ce qui leur est commun : l’envoi effectif d’une réponse texte au client :

<?php

namespace Application;

// dépendances Symfony
use Symfony\Component\HttpFoundation\Response;

class ParentResponse {

  // int $statusCode : le code HTTP de statut de la réponse
  // string $content : le corps de la réponse à envoyer
  // selon les cas, c'est une chaîne jSON, XML, HTML
  // array $headers : les entêtes HTTP à ajouter à la réponse

  public function sendResponse(
    int $statusCode,
    string $content,
    array $headers): void {

    // préparation de la réponse texte du serveur
    $response = new Response();
    $response->setCharset("utf-8");
    // code de statut
    $response->setStatusCode($statusCode);
    // headers
    foreach ($headers as $text => $value) {
      $response->headers->set($text, $value);
    }
    // on envoie la réponse
    $response->setContent($content);
    $response->send();
  }
}

Commentaires

• lignes 10-13 : la signification des trois paramètres de la méthode [send] ;
• ligne 17 : on notera que le corps de la réponse est de type [string] et donc prêt à être envoyé (ligne 30) ;
• ligne 22 : la réponse aura des caractères UTF-8 ;
• ligne 24 : code de statut HTTP de la réponse ;
• lignes 26-28 : ajout des entêtes HTTP donnés par le code appelant ;
• lignes 30-31 : envoi de la réponse au client ;

Rappelons enfin le code du contrôleur principal qui demande l’envoi de la réponse au client :

// on ajoute les clés [action, état] à la réponse du contrôleur
$content = ["action" => $action, "état" => $état] + $content;
// on instancie l'objet [Response] chargée d'envoyer la réponse au client
$response = __NAMESPACE__ . $config["types"][$type]["response"];
(new $response())->send($request, $session, $config, $statusCode, $content, $headers, $logger);

// la réponse a été envoyée - on libère les ressources
$logger->close();
exit;

• ligne 4 : on fixe le nom de la classe [Response] à instancier ;
• ligne 5 : on l’instancie et on envoie la réponse au client grâce à la méthode [send($request, $session, $config, $statusCode, $content, $headers, $logger)]. Parce qu’elles implémentent la même interface [InterfaceResponse], les méthodes [send] des différents types de réponse ont toutes la même signature ;

Elle a déjà présentée au paragraphe lien[main.php] – 2. Nous redonnons cependant son code pour mieux souligner l’homogénéité des trois classes de réponse :

La classe [JsonResponse] implémente l’interface [InterfaceResponse] de la façon suivante :

<?php

namespace Application;

// dépendances Symfony
use Symfony\Component\Serializer\Encoder\JsonEncode;
use Symfony\Component\Serializer\Encoder\JsonEncoder;
use Symfony\Component\Serializer\Normalizer\ObjectNormalizer;
use Symfony\Component\Serializer\Serializer;
use \Symfony\Component\HttpFoundation\Request;
use \Symfony\Component\HttpFoundation\Session\Session;

class JsonResponse extends ParentResponse implements InterfaceResponse {

  // Request $request : requête en cours de traitement
  // Session $session : la session de l'application web
  // array $config : la configuration de l'application
  // int statusCode : le code HTTP de statut de la réponse
  // array $content : la réponse du serveur
  // array $headers : les entêtes HTTP à ajouter à la réponse
  // Logger $logger : le logueur pour écrire des logs

  public function send(
    Request $request = NULL,
    Session $session = NULL,
    array $config,
    int $statusCode,
    array $content,
    array $headers,
    Logger $logger = NULL): void {

    // préparation sérialiseur symfony
    $serializer = new Serializer(
      [
      // nécessaire pour la sérialisation d'objets
      new ObjectNormalizer()],
      // encodeur jSON
      // pour les options, faire des OU entre les différentes options
      [new JsonEncoder(new JsonEncode([JsonEncode::OPTIONS => JSON_UNESCAPED_UNICODE]))]
    );
    // sérialisation jSON
    $json = $serializer->serialize($content, 'json');
    // headers
    $headers = array_merge($headers, ["content-type" => "application/json"]);
    // envoi réponse
    parent::sendResponse($statusCode, $json, $headers);
    // log
    if ($logger !== NULL) {
      $logger->write("réponse=$json\n");
    }
  }

}

Commentaires

• ligne 13 : la classe implémente l’interface [InterfaceResponse] ;
• ligne 13 : la classe étend la classe [ParentResponse]. Tous les types de [Response] étendent cette classe. C’est cette classe parent qui envoie la réponse au client (ligne 46). C’est parce que ce code était commun à tous les types de [Response] qu’il a été factorisé dans une classe parent ;
• lignes 33-40 : instanciation du sérialiseur [Symfony] qui va traduire la réponse du serveur [$content] en chaîne jSON (ligne 42) ;
• lignes 34-36 : le 1^er paramètre du constructeur de [Serializer] est un tableau. Dans celui-ci, on met une instance de la classe [ObjectNormalizer] nécessaire à la sérialisation d’objets. Ce cas se présente dans cette application avec une liste de simulations où chaque simulation est une instance de la classe [Simulation] ;
• ligne 39 : le second paramètre du constructeur de [Serializer] est également un tableau : on y met tous les encodeurs utilisés dans une sérialisation (XML, jSON, CSV…) ;
• ligne 39 : il n’y aura qu’un encodeur ici, de type [JsonEncoder]. Le constructeur sans paramètres aurait pu être suffisant. Ici, nous avons passé un paramètre [JsonEncode] au constructeur, uniquement pour passer des options d’encodage jSON ;
• ligne 39 : le paramètre du constructeur [JsonEncode] est un tableau d’options. Ici on utilise l’option [JSON_UNESCAPED_UNICODE] pour demander que les caractères UTF-8 de la chaîne jSON soient rendus nativement et non pas « échappés » ;
• ligne 42 : le corps de la réponse HHTP est sérialisé en jSON grâce au sérialiseur précédent ;
• ligne 44 : on ajoute l’entête HTTP qui dit au client qu’on va lui envoyer du jSON ;
• ligne 46 : on demande à la classe parent d’envoyer la réponse au client ;
• lignes 48-50 : on logue la réponse jSON ;

La classe [XmlResponse] implémente l’interface [InterfaceResponse] de la façon suivante :

<?php

namespace Application;

// dépendances Symfony
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Session\Session;
use Symfony\Component\Serializer\Encoder\JsonEncode;
use Symfony\Component\Serializer\Encoder\JsonEncoder;
use Symfony\Component\Serializer\Encoder\XmlEncoder;
use Symfony\Component\Serializer\Normalizer\ObjectNormalizer;
use Symfony\Component\Serializer\Serializer;

class XmlResponse extends ParentResponse implements InterfaceResponse {

  // Request $request : requête en cours de traitement
  // Session $session : la session de l'application web
  // array $config : la configuration de l'application
  // int statusCode : le code HTTP de statut de la réponse
  // array $content : la réponse du serveur
  // array $headers : les entêtes HTTP à ajouter à la réponse
  // Logger $logger : le logueur pour écrire des logs

  public function send(
    Request $request = NULL,
    Session $session = NULL,
    array $config,
    int $statusCode,
    array $content,
    array $headers,
    Logger $logger = NULL): void {

    // préparation sérialiseur symfony
    $serializer = new Serializer(
      // nécessaire pour la sérialisation d'objets
      [new ObjectNormalizer()],
      [
      // sérialisation XML
      new XmlEncoder(
        [
        XmlEncoder::ROOT_NODE_NAME => 'root',
        XmlEncoder::ENCODING => 'utf-8'
        ]
      ),
      // sérialisation jSON
      new JsonEncoder(new JsonEncode([JsonEncode::OPTIONS => JSON_UNESCAPED_UNICODE]))
      ]
    );
    // sérialisation XML
    $xml = $serializer->serialize($content, 'xml');
    // headers
    $headers = array_merge($headers, ["content-type" => "application/xml"]);
    // envoi réponse
    parent::sendResponse($statusCode, $xml, $headers);
    // log
    if ($logger !== NULL) {
      // log en jSON
      $log = $serializer->serialize($content, 'json');
      $logger->write("réponse=$log\n");
    }
  }

}

Commentaires

• lignes 34-48 : instanciation d’un sérialiseur Symfony. Le constructeur admet deux paramètres de type tableau ;
• ligne 36 : le 1^er tableau comprend une instance de type [ObjectNormalizer] qui intervient dans la sérialisation d’objets ;
• lignes 37-47 : le second tableau contient les encodeurs utilisés pour la sérialisation. On peut prévoir divers types de sérialisation avec le même sérialiseur ;
• lignes 38-44 : l’encodeur XML ;
• ligne 41 : on fixe la racine du code XML généré. Celui-ci aura la forme <root>[autres balises XML]</root> ;
• ligne 42 : l’encodage utilisera des caractères UTF-8 ;
• ligne 46 ; l’encodeur jSON. Celui-ci sera utilisé pour le log de la réponse dans le fichier [logs.txt] qui est fait en jSON ;
• ligne 50 : le corps de la réponse envoyée au client est sérialisée en XML ;
• ligne 52 : on ajoute aux entêtes reçus en paramètre (ligne 30) l’entête HTTP qui indique au client qu’on lui envoie un document XML ;
• ligne 54 : envoi effectif de la réponse au client par la classe parent ;
• lignes 56-60 : log en jSON de la réponse ;

Nous avons déjà fait tous les tests d’erreurs possibles en jSON. Il n’y a rien à faire de plus en XML. Nous montrons deux exemples de réponse XML :

Ci-dessus :

• en [1-3], la requête de début de session XML ;
• en [4-7], la réponse XML du serveur ;

A partir de maintenant, toutes les réponses du serveur seront en XML. On peut reprendre toutes les requêtes déjà utilisées dans [Postman] sans les changer et on aura pour chacune d’elles une réponse XML. Faisons par exemple une authentification réussie :

Ci-dessus :

• en [1-3], une demande d’authentification valide ;
• en [4-7], la réponse XML du serveur ;

Lorsque le type de la session est [html] un objet de type [HtmlResponse] est instancié pour envoyer la réponse au client. Celle-ci va envoyer au client un flux HTML qui dépend du code d’état rendu par le contrôleur secondaire qui a traité l’action. Cette correspondance [état=>vue] est inscrite dans le fichier de configuration [config.json] de la façon suivante :

"vues": {
        "vue-authentification.php": [700, 221, 400],
        "vue-calcul-impot.php": [200, 300, 341, 350, 800],
        "vue-liste-simulations.php": [500, 600]
    },
"vue-erreurs": "vue-erreurs.php"

Cette configuration se lit de la façon suivante : [‘nom de la vue’ => ‘états associés à cette vue’]

• ligne 2 : si le contrôleur secondaire a rendu un état du tableau [700, 221, 400], alors il faut afficher la vue [vue-authentification.php] ;
• ligne 3 : si le contrôleur secondaire a rendu un état du tableau [200, 300, 341, 350, 800], alors il faut afficher la vue [vue-calcul-impot.php] ;
• ligne 4 : si le contrôleur secondaire a rendu un état du tableau [500, 600], alors il faut afficher la vue [vue-liste-simulations.php] ;
• ligne 6 : si le contrôleur secondaire a rendu un état qui n’est dans aucun des tableaux précédents, alors il faut afficher la vue [vue-erreurs.php] ;

Les vues sont rassemblées dans le dossier [Views] du projet :

Le code de la classe [HtmlResponse] est le suivant :

<?php

namespace Application;

// dépendances Symfony
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Session\Session;
use Symfony\Component\Serializer\Encoder\JsonEncode;
use Symfony\Component\Serializer\Encoder\JsonEncoder;
use Symfony\Component\Serializer\Normalizer\ObjectNormalizer;
use Symfony\Component\Serializer\Serializer;

class HtmlResponse extends ParentResponse implements InterfaceResponse {

  // Request $request : requête en cours de traitement
  // Session $session : la session de l'application web
  // array $config : la configuration de l'application
  // int statusCode : le code HTTP de statut de la réponse
  // array $content : la réponse du serveur
  // array $headers : les entêtes HTTP à ajouter à la réponse
  // Logger $logger : le logueur pour écrire des logs

  public function send(
    Request $request = NULL,
    Session $session = NULL,
    array $config,
    int $statusCode,
    array $content,
    array $headers,
    Logger $logger = NULL): void {

    // préparation sérialiseur symfony
    $serializer = new Serializer(
      [
      // pour la sérialisation des objets
      new ObjectNormalizer()],
      [
      // pour la sérialisation jSON du log de la réponse
      new JsonEncoder(new JsonEncode([JsonEncode::OPTIONS => JSON_UNESCAPED_UNICODE]))
      ]
    );
    // la réponse HTML dépend du code d'état rendu par le contrôleur
    $état = $content["état"];
    // à un état, correspond une vue - on cherche celle-ci dans la configuration de l'application
    // la liste des vues
    $vues = array_keys($config["vues"]);
    $trouvé = false;
    $i = 0;
    // on parcourt la liste des vues
    while (!$trouvé && $i < count($vues)) {
      // états associés à la vue n° i
      $états = $config["vues"][$vues[$i]];
      // est-ce que l'état cherché se trouve dans les états associés à la vue n° I ?
      if (in_array($état, $états)) {
        // la vue affichée sera la vue n° i
        $vueRéponse = $vues[$i];
        $trouvé = true;
      }
      // vue suivante
      $i++;
    }
    // trouvé ?
    if (!$trouvé) {
      // si aucune vue n'existe pour l'état actuel de l'application
      // on rend la vue d'erreurs
      $vueRéponse = $config["vue-erreurs"];
    }
    // on récupère la vue HTML à afficher dans une chaîne de caractères
    ob_start();
    require __DIR__ . "/../Views/$vueRéponse";
    $html = ob_get_clean();
    // on indique dans les entêtes qu'on va envoyer du HTML
    $headers = array_merge($headers, ["content-type" => "text/html"]);
    // la classe parent s'occupe de l'envoi effectif de la réponse
    parent::sendResponse($statusCode, $html, $headers);
    // log en jSON de la réponse sans le HTML
    if ($logger !== NULL) {
      // log en jSON de la réponse du contrôleur secondaire qui a traité l'action
      $log = $serializer->serialize($content, 'json');
      $logger->write("réponse=$log\n");
    }
  }

}

Commentaires

• lignes 32-41 : on instancie un sérialiseur Symfony. Celui-ci est nécessaire pour le log jSON de la réponse du contrôleur qui a traité l’action (lignes 72-82) ;
• lignes 42-57 : on cherche dans la configuration de l’application, la vue qui doit être affichée. Celle-ci dépend du code d’état rendu par le contrôleur qui a traité l’action. Ce code est dans [$content[‘état’]] (ligne 43) ;
• lignes 42-61 : on cherche la vue qui correspond à cet état ;
• lignes 62-67 : si aucune vue n’a été trouvée alors on est dans une situation d’un code d’état anormal pour l’application HTML. On explicitera plus loin cette notion d’états anormaux. Dans ce cas, on affiche une vue d’erreur ;
• lignes 68-70 : on interprète le code PHP de la vue sélectionnée et on met le résultat dans la variable [$html] (ligne 71) ;
• ce code mérite quelques explications. Imaginons que la vue sélectionnée soit [vue-authentification.php] qui présente un formulaire web d’authentification :
  • ligne 69 : la fonction [ob_start] démarre ce que la documentation appelle une temporisation de sortie. Tout ce qui est écrit par des opérations print, require… et qui normalement est immédiatement envoyé au client, va dans un tampon de sortie (ob=output buffer) sans être envoyé au client ;
  • ligne 70 : on charge la vue [vue-authentification.php] qui est une vue HTML dynamique contenant du code PHP. Se passent alors deux choses :
    • le code PHP de la vue [vue-authentification.php] est chargé et interprété. Le résultat est une vue qu’on appellera [vue-authentification.html] qui ne contient que du code HTML, voire CSS et Javascript mais plus de PHP ;
    • ce code HTML est normalement envoyé au client. C’est en fait le cas de tout texte rencontré par l’interpréteur PHP et qui n’est pas du code PHP. A cause de la temporisation de sortie, ce code HTML est mis dans le tampon de sortie sans être envoyé au client ;
  • ligne 71 : la fonction [ob_get_clean] fait deux choses :
    • elle met dans la variable [$html] le contenu du buffer de sortie, donc la page [vue-authentification.html] qu’on y a mise ;
    • elle vide le buffer de sortie. Pour celui-ci, tout se passe comme si rien ne s’était produit. Par ailleurs, le client n’a toujours rien reçu ;
• ligne 70 : on est ici en cours d’exécution de la classe [HtmlResponse] qui se trouve dans le dossier [Responses]. Pour touver la vue, il faut donc remonter d’un niveau [..] puis passer dans le dossier [Views]. [__DIR__] est le nom absolu du dossier dans lequel se trouve le script en cours d’exécution, dans notre exemple le dossier [C:/myprograms/laragon-lite/www/php7/scripts-web/impots/13/Responses] ;
• ligne 73 : on ajoute aux entêtes HTTP reçus en paramètre (ligne 29), l’entête qui dit au client qu’on va lui envoyer du HTML ;
• ligne 75 : on demande à la classe parent de procéder à l’envoi effectif de la réponse au client ;
• lignes 77-81 : on logue en jSON la réponse [$content] fournie par le contrôleur secondaire qui a traité l’action en cours ;

Pour tester véritablement le mode HTML de la session, il nous faudrait passer en revue toutes les vues. Nous allons le faire ultérieurement. Nous allons faire le test suivant :

Regardons la liste des vues dans le fichier de configuration :

"vues": {
        "vue-authentification.php": [700, 221, 400],
        "vue-calcul-impot.php": [200, 300, 341, 350, 800],
        "vue-liste-simulations.php": [500, 600]
    },
    "vue-erreurs": "vue-erreurs.php"

On peut trouver le contexte produisant certains des codes d’état ci-dessus en regardant les tests [Postman] réalisés :

On voit que le code d’état [700] est celui d’une action [init-session] réussie [2]. Ci-dessus, on a une réponse jSON mais elle peut être de type XML ou HTML. C’est ce dernier cas qui va être testé. D’après le fichier de configuration, c’est la vue [vue-authentification.php] qui constitue la réponse HTML. Vérifions.

Ci-dessus :

• en [1-3], on initialise une session HTML. On attend donc une réponse HTML ;
• en [4-8], la réponse HTML du serveur ;
• l’onglet [8] permet d’avoir une prévisualisation du code HTML reçu ;

• en [8-9], un aperçu de la vue HTML ;

L’application web HTML utilisera quatre vues :

La vue d’authentification :

La vue de calcul de l’impôt :

La vue de la liste des simulations :

La vue des erreurs inattendues :

Nous allons décrire ces vues l’une après l’autre.

XXIII-M-2-a. Présentation de la vue▲

La vue d’authentification est la suivante :

La vue est composée de deux éléments qu’on appellera des fragments :

• le fragment [1] est généré par un script [v-bandeau.php] ;
• le fragment [2] est généré par un script [v-authentification.php] ;

La vue d’authentification est générée par la page [vue-authentification.php] suivante :

 

Sélectionnez

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.

<?php
// données de test de la page
// on encapsule les données de la page dans $page
…
?>

<!doctype html>
<html lang="fr">
    <head>
        <!-- Required meta tags -->
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
        <!-- Bootstrap CSS -->
        <link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/bootstrap/4.1.3/css/bootstrap.min.css" integrity="sha384-MCw98/SFnGE8fJT3GXwEOngsV7Zt27NXFoaoApmYm81iuXoPkFOJwJ8ERdknLPMO" crossorigin="anonymous">
        <title>Application impots</title>
    </head>
    <body>
        <div class="container">
            <!-- bandeau sur 1 ligne et 12 colonnes -->
            <?php require "v-bandeau.php"; ?>
            <!-- formulaire d'authentification sur 9 colonnes -->
            <div class="row">
                <div class="col-md-9">
                    <?php require "v-authentification.php" ?>
                </div>
            </div>  
            <?php
            // si erreur - on affiche une alerte d'erreur
            if ($modèle->error) {
              print <<<EOT
            <div class="row">                
                <div class="col-md-9">
                    <div class="alert alert-danger" role="alert">
                      Les erreurs suivantes se sont produites :
                      <ul>$modèle->erreurs</ul>
                    </div>
                </div>
            </div>
EOT;
            }
            ?>
        </div>
    </body>
</html>

Commentaires

• ligne 7 : un document HTML commence avec cette ligne ;
• lignes 8-44 : la page HTML est encapsulée dans les balises <html> </html> ;
• lignes 9-16 : entête (head) du document HTML ;
• ligne 11 : la balise <meta charset> indique que le document est codé en UTF-8 ;
• ligne 12 : la balise <meta name=’viewport’> fixe l’affichage initial de la vue : sur toute la largeur de l’écran qui l’affiche (width) à sa taille initiale (initial-scale) sans redimensionnement pour s’adapter à une taille plus petite d’écran (shrink-to-fit) ;
• ligne 14 : la balise <link rel=’stylesheet’> fixe le fichier CSS qui gouverne l’apparence de la vue. Nous utilisons ici le framework CSS Bootstrap 4.1.3 [https://getbootstrap.com/docs/4.0/getting-started/introduction/] ;
• ligne 15 : la balise <title> fixe le titre de la page :

• lignes 17-43 : le corps de la page web est encapsulé dans les balises <body></body> ;
• lignes 18-42 : la balise <div> délimite une section de la page affichée. Les attributs [class] utilisés dans la vue se réfèrent tous au framework CSS Bootstrap. La balise <div class=’container’> délimite un conteneur Bootstrap ;
• ligne 20 : on inclut le script [v-bandeau.php]. Ce script génère le bandeau [1] de la page. Nous le décrirons bientôt ;
• lignes 22-26 : la balise <div class=’row’> délimite une ligne Bootstrap. Ces lignes sont constituées de 12 colonnes ;
• ligne 23 : la balise <div class=’col-md-9’> délimite une section de 9 colonnes ;
• ligne 24 : on inclut le script [v-authentification.php] qui affiche le formulaire d’authentification [2] de la page. Nous le décrirons bientôt ;
• ligne 27 : la balise <?php introduit du code PHP à l’intérieur de la page HTML. Ce code est exécuté avant l’affichage de la page HTML et peut modifier celle-ci ;
• ligne 29 : la totalité des données dynamique de la vue affichée sera encapsulée dans un objet [$modèle] de type [stdClass]. C’est un choix arbitraire. On aurait pu choisir un tableau associatif à la place pour le même résultat ;
• ligne 29 : l’authentification échoue si l’utilisateur entre des identifiants incorrects. Dans ce cas, la vue d’authentification est réaffichée avec un message d’erreur. L’attribut [$modèle->error] indique s’il faut afficher ce message d’erreur ;
• lignes 30-39 : cette syntaxe écrit tout le texte placé entre les symbole PHP <<<EOT (ligne 30 – on peut mettre ce qu’on veut à la place de EOT=End Of Text) et le symbole EOT de la ligne 39 (doit être identique au symbole utilisé ligne 30). Le symbole doit être écrit dans la 1^re colonne de la ligne 39. Les variables PHP situées dans le texte entre les deux symboles EOT sont interprétées ;
• lignes 33-36 : délimitent une zone à fond rose (class="alert alert-danger") (ligne 33) ;

• ligne 34 : un texte ;
• ligne 35 : la balise HTML <ul> (unordered list) affiche une liste à puces. Chaque élément de la liste doit avoir la syntaxe <li>élément</li> ;

Retenons de ce code les éléments dynamiques à définir :

• [$modèle->error] : pour afficher un message d’erreur ;
• [$modèle->erreurs] : une liste (au sens HTML du terme) de messages d’erreur ;

XXIII-M-2-b. Le fragment [v-bandeau.php]▲

Le fragment [v-bandeau.php] affiche le bandeau supérieur de toutes les vues de l’application web :

Le code du fragment [v-bandeau.php] est le suivant :

 

Sélectionnez

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.

<!-- Bootstrap Jumbotron -->
<div class="jumbotron">
    <div class="row">
        <div class="col-md-4">
            <img src="<?= $logo ?>" alt="Cerisier en fleurs" />
        </div>
        <div class="col-md-8">
            <h1>
                Calculez votre impôt
            </h1>
        </div>
    </div>
</div>

Commentaires

• lignes 2-13 : le bandeau est encapsulé dans une section Bootstrap de type Jumbotron [<div class="jumbotron">]. Cette classe Bootstrap stylise d’une façon particulière le contenu affiché pour le faire ressortir ;
• lignes 3-12 : une ligne Bootstrap ;
• lignes 4-6 : une image [img] est placée dans les quatre premières colonnes de la ligne ;
• ligne 5 : la syntaxe [<?= $logo ?>] est équivalente à la syntaxe [<?php print $logo ?>]. Dit autrement la valeur de l’attribut [src] sera la valeur de la variable PHP [$logo] ;
• lignes 7-11 : les 8 autres colonnes de la ligne (on rappelle qu’il y en a 12 au total) serviront à placer un texte (ligne 9) en gros caractères (<h1>, lignes 8-10) ;

Eléments dynamiques :

• [$logo] : URL de l’image affichée dans le bandeau ;