Portail / Sujets autour de la programmation / Programmation C/C++ sous Linux / Serveur d'application avec Qt 6 / Documentation technique(Sommaire)

Réalisation d'une application de test.

Mise à jour du 14/11/2024.

Pour pouvoir mettre au point le serveur d'application, il faut pouvoir disposer d'ua moins un application web. Comme nous l'avons vu, pour pouvoir être lancé de manière générique directement depuis le serveur, cette application, ses services et ses ressources doivent être enregsitrées au sein d'une librairie dynamique qui sera déclarée dans la configuration du serveur et chargée dynamiquement par ce dernier.

Contexte d'emploi.

Pour permettre l'accès à des ressources statiques (Bootstrap), le serveur d'application soutiendra deux 2 applications :

1. La première est l'application de gestion de sites statiques de classe WebSite. Cette application soutiendra deux sites :

   1. Le premier donnera accès aux librairies Bootstrap référencées par le chemin /doc/bs.
   2. Le second sera un site interne référencé par le chemin /doc auquel sera associé un sous-répertoire supportant les ressources à délivrer.

2. La seconde application se nommera "pastest" et sera une application spécifique de classe PasTest. Son contexte de commutation sera /test. Le détail de fonctionnament de l'application est décrit dans le chapitre suivant.

Application "pastest".

Généralités.

En matière d'application web, il existe 2 fonctions techniques incontournables et 3 grandes familles de fonctions :

Les fonctions techniques incontournables sont :

• La demande d'authentification généralement associée à une lecture de données stockées dans une base relationnelle ;
• La présentation des erreurs critiques rencontrées lors des traitements. A ce niveau on distingue les erreurs fatales qui interdisent la poursuite de la session de travail, des erreurs critiques qui interromptent un traitement mais n'interdisent pas la porsuite de la session de navigation.

Les 3 grandes familles de fonctions, quant à elles, sont ;

• La gestion d'un formulaire de saisie de données ;
• Le téléchargement (du serveur vers le client) d'un fichier ou d'un flux binaire ;
• Le téléversement (du client vers le serveur) d'un fichier choisi depuis le système de fichier local du client.

Spécifications fonctionnelles du prototype.

Notre application de test met en oeuvre ces fonctions :

La liste des fonctions proposées est la suivante :

• Affichage d'une page d'erreur de test avec un lien retour vers la page de présentation des fonctions.
• Présentation d'une page de formulaire. A la suite de son envoi, les données reçues sont affichées et un lien permet un retour vers la page de présentation des fonctions.
• Présentation d'un lien de téléchargement du contenu d'un fichier de test. A la suite de son envoi, les caractéristiques du fichier émis sont affichées et un lien permet un retour vers la page de présentation des fonctions.
• Présentation d'une page de téléversement. cette page permet le choix d'un fichier local qulconque pour envoi au serveur. A la suite de son envoi, les caractéristiques du fichier reçu sont affichées et un lien permet un retour vers la page de présentation des fonctions.

Spécifications techniques du prototype.

Ici on fait le choix d'afficher une erreur fatale par un document plein-texte (non HTML) accompagné d'un statut d'erreur HTTP. Les erreurs critiques sont, quant à elles, affichées par un service dédié (document HTML) qui dispose d'un lien autorisant la poursuite de l'application. (error).

Le service d'authentification permet d'illustrer la création d'un gestionnaire de connexions PostgreSQL utilisé pour accéder à la table t_account du schéma pastest. Voici le code SQL de création de cette unique table :

CREATE TABLE t_account (
    c_id bigint NOT NULL,
    c_account character varying(16),
    c_password character varying(64),
    c_fullname character varying(128),
    CONSTRAINT t_account_pkey PRIMARY KEY (c_id)
)

Pour vos tests, vous devrez créer au moins un compte via par exemple la requête SQL :

INSERT INTO t_account
(c_id,c_account,c_password,c_fullname)
VALUES 
(0,'test','secret','M. Jean Inconnu')

Le schéma qui suit modélise la cinématique d'enchaînement des pages. Notez que, pour des raisons didactiques, nous avons volontairement séparé les pages de requêtes des pages de réponses. Dans les applications réelles elles sont souvent confondues pour permettre à l'utilisateur d'émettre depuis la même page une nouvelle requête suite à la réponse reçue (exemple : interrogation d'un moteur de recherche ou ici le service home).

Rappel : à un service correspond au plus une page

Si la règle ci-dessus n'est pas respectée, vous vivrez des moments "intéressants" lors de l'évolution ou de la maintenance corrective de l'application.

Notre application de test comporte au total 9 services :

• "error" de classe SrvError pour la gestion des erreurs critiques. Lorsqu'une application ou un service rencontre une erreur critique, c'est ce service qui est invoqué. La page produite permet la poursuite de l'application. Notez que dans notre prototype, par mesure de simplification, les erreurs fatales sont affichées sous forme d'un texte et non d'un flux HTML.
• "home" de classe SrvLogin pour la saisie des éléments d'authentification. Ce service émet la page de saisie des données d'authentification. Ce service boucle sur lui-même tant que l'authentification n'est pas positive. Il est automatiqument invoqué par l'infrastructure lorsque la session est perdue. C'est à lui d'initier la session une fois l'authenfication validée.
• "functions" de classe SrvFunctions pour la présentation d'une page de liens qui donne accès aux fonctions de l'application. Ce service sert de service "recueil"". Le service recueil joue le rôle de page d'accueil lorsque l'identifiant transmis correspond à uen session vivante. La déclaration d'un service recueil n'est pas obligatoire. Elle s'effectue dans le fichier de configuration de l'application dérivée de la classe WebApp via la propriété recovery. Lorsqu'il est déclaré, le service recueil est utilisé automatiquement par l'infrastructure dans deux cas :
  1. la session est vivante mais le service invoqué n'est pas déclaré (application en cours de développement par exemple) ;
  2. le chemin de l'URL invoque le chemin de routage vers l'application sans déclaration du paramètre srv ni même d'aucun paramètre (contexte racine).
• "formrequest" de classe SrvFormRequest pour la présentation de la page de saisie du formulaire.
• "formresponse" de classe SrvFormResponse pour la présentation de la page d'affichage du contenu du formulaire.
• "filesuploadrequest" de classe SrvFilesUploadRequest pour la présentation de la page de téléversement d'un fichier.
• "filesuploadresponse" de classe SrvFilesUploadResponse pour la présentation de la page affichant les caractéristiques du fichier téléversé.
• "filesdownloadrequest" de classe SrvFilesDownloadRequest pour le téléchargement d'un fichier (ici un PDF). Ce service illustre l'envoi d'un flux non HTML mais d'un type MIME donné (ici application/pdf). C'est le client (en général un navigateur) qui décide s'il exploite le type MIME (affichage du PDF par le client) ou s'il propose son téléchargement. Pour les types MIME moins généralisés, la plupart des navigateurs proposent le téléchargement du flux reçu. Il est possible de forcer le téléchargement plutôt que l'affichage des flux de type MIME supporté en utilisant l'attribut download (avec ou sans précision du nom du fichier à sauvegarder côté client).