LIFAP5 - Projet : gestionnaire de débat - version du 05/04/19

L’objectif de ce projet est de mettre en pratique ce qui a été vu dans l’UE LIFAP5 à travers la réalisation de la partie client, entièrement en javascript dans le navigateur, d’une application minimaliste de gestion de débats. Le projet est à réaliser en binôme constitué au sein du même groupe de TD (ou éventuellement en monôme).

Attention: il est important de lire tout l’énoncé avant de commencer à coder. De plus, lire le projet en entier vous permettra de mieux comprendre où vous allez.

Attention: Un projet de départ vous est fourni.

Attention: Le serveur https://lifap5.univ-lyon1.fr est en ligne

Versions du document

Maquette de l’application

On souhaite réaliser un gestionnaire de débat, c’est-à-dire une forme de forum, ici simplifié pour les besoins pédagogiques. Ci-après, une esquisse générale de l’interface de l’application avec ses principales fonctionnalités (dont certaines optionnelles).

Attention : il ne s’agit pas de reproduire l’image au pixel près en HTML, bien au contraire : vous êtes libres de déplacer le header, le footer, de ne pas utiliser d’icônes : ce que vous voulez, tant que les fonctionnalités sont là.

Fonctionnalités du gestionnaire de débat

Le forum est une collection de sujets (appelés topics dans l’API) postés par ses utilisateurs (users). Chaque sujet a une description et une liste de contributions (posts) saisies par les utilisateurs. Voir la description des fichiers json pour plus de détails. Les fonctionnalités attendues du forum sont les suivantes :

Fonctionnalités obligatoires :

Fonctionnalités optionnelles (vous devez en réaliser au moins une dans chaque bloc pour avoir la note maximale) :

Conseils pour le développement du client

Étapes du projet, évaluation

Trois séances sont fléchées à l’emploi du temps sur ce projet : le 08/04, le 29/04 et le 13/05 (jour de la soutenance). La permanence entre les séances est assurée via Le canal projet du framateam

Dans un premier temps vous travaillerez en local en lecture seule. Ensuite, l’hébergement des listes de tâches se fera sur un serveur dédié géré par l’université (voir la section Serveur). Les grandes étapes du projet, appelées jalons, sont les suivantes.

Jalon 1 : maquette de l’application

Un projet de départ vous est fourni pour démarrer le projet, il est constitué des fichiers LIFAP5-Projet.js et LIFAP5-Projet.html et des fichiers json. La page HTML est une maquette statique HTML/CSS à l’image de l’esquisse proposée plus haut. Vous êtes libres de la reprendre.

Attention : créer un projet sur forge.univ-lyon1.fr pour versionner votre code et travailler à plusieurs. C’est une bonne pratique à acquérir.

Attention : vous pouvez tout à fait entrelacer la réalisation des jalons 1 et 2, en ajoutant progressivement des éléments dans l’interface et en créant le code js correspondant

Jalon 2 : génération dynamique sans serveur

Ensuite, vous devez dynamiser votre maquette : tout le HTML statique sera générée à partir des collections Projet-2019-users.json Projet-2019-topics.json lues en local avec l’API fetch (voir plus loin pour le détail de ces données).

Il est très important de travailler dès cette partie en asynchrone, le passage à un vrai serveur à la place des fichiers locaux sera facilité.

Attention : le jalon 2 correspond essentiellement à refaire dans le projet ce que vous avez fait dans le TP3/4 .

Attention : si vous savez ce que vous faites, vous pouvez sauter cette étape et travailler directement sur le serveur.

Jalon 3 : accès au serveur

Attention : alors qu’avec les fichiers locaux vous avez directement accès à l’intégralité de la collection des sujets avec une seule requête fetch, ce ne sera pas le cas avec le serveur. Pour accéder aux contributions d’un sujet, il faudra faire 3 requêtes voir l’API des topics :

  1. obtenir la liste des topics avec GET /topic/
  2. obtenir sa description avec GET /topic/:id
  3. obtenir la liste des posts avec GET /topic/:id/posts/

Une solution intermédiaire pour passer du jalon 2 au jalon 3 est de faires tous les appels serveurs une bonne fois pour toutes afin de reconstituer l’intégralité du document json. Ensuite, vous serez plus malins et ne chargerez que les posts dont vous avez besoin.

Modalité d’évaluation

Le projet est à réaliser en binôme constitué au sein du même groupe de TD (ou éventuellement en monôme). Pour les binômes “à cheval”, demandez au responsable d’UE de vous changer de groupe de TD.

Dépôt du code

Une archive zip est à déposer pour la même date, 8h du matin, sur Tomuss dans la cellule Depot_Projet de UE-INF2026L Programmation Fonctionnelle Pour Le Web Votre fichier zip contiendra tous vos fichiers html, js et les fichiers statiques (e.g., images) éventuellement utilisés ainsi qu’un fichier README.txt contenant vos noms, prénoms et d’éventuels commentaires.

Soutenance

Chaque binôme présentera son projet à son encadrant de TP le lundi 13/05 au matin. Un ordre de passage sera fixé sur Tomuss en temps utile. La soutenance durera 10 minutes par projet, dont environ 5 minutes de présentations et 5 minutes de discussion.

Critères d’évaluation

Attention : comme dans le TP3/4 il s’agit d’écrire un programme le plus fonctionnel possible. Le manquement à cette consigne sera fortement pénalisé dans le critère de qualité générale du code.

Lors de la soutenance vous serez évalués avec le barème (prévisionnel) suivant :

Description technique

Données sur les sujets (topics), les contributions (posts) et les utilisateurs (users) au format json.

Schémas json

Utilisateurs (users)

Chaque utilisateur est représenté en base par un objet JSON composé des champs suivants. Une liste d’utilisateurs est simplement un tableau d’utilisateurs, voir le fichier Projet-2019-users.json.

Sujet (topics) et contributions (_posts)

Chaque sujet de débat est représenté par un objet json composé des champs suivants. Une liste de sujets est simplement un tableau de sujets, voir le fichier Projet-2019-topics.json.

Accès au serveur

Un serveur Web est déployé sur la machine https://lifap5.univ-lyon1.fr avec une API Web pour accéder en lecture et en écriture. Les accès en écriture nécessitent de s’authentifier à chaque requête voir ci-après.

Chacune des fonctionnalités du serveur est accessible via une méthode HTTP et une route , c’est-à-dire un chemin relatif sur le serveur, comme par exemple POST /echo.

Authentification sur le serveur

Certaines interactions avec le serveur nécessitent d’être authentifié auprès de ce dernier, c’est-à-dire qu’une requête ne sera acceptée par le serveur que s’il peut l’associer à un utilisateur et que cet utilisateur a le droit de faire cette requête. Il est par exemple interdit de supprimer une contribution créée par un autre utilisateur.

Afin de s’authentifier auprès du serveur, chaque utilisateur dispose d’une clef (d’API), composée d’une suite de caractères unique à chaque utilisateur, disponible dans tomuss (dans la case apikey).

Cette clé doit être transmise dans le header HTTP x-api-key qui est configurée avec une valeur par défaut dans les projet de départ. Un exemple d’utilisation de de fetch utilisant cette authentification est fourni avec la fonction whoami() qui utilise la route /whoami.

Pour tester, exécuter let state = new State; state.x_api_key = "MA_CLEF_TOMUSS"; whoami(state)().then(console.log); doit vous renvoyer un objet json qui vous décrit et qui comporte dont votre numéro d’étudiant (associé à votre clef x-api-key).

API rest

API de test

API user

API topic

API posts

API WebSocket

Le serveur diffuse en temps-réel les mises à jours effectuées dans la base de données via un WebSocket sur la route /stream/. Les messages des objets JSON séralisés de la forme suivante :

{ "type":"insert",                    // ou "delete", "update" et "info"
  "_id":"5cc45570d411480907a1438c",   // l'identifiant du topic modifié
  "time":1556370800                   // l'heure du serveur Mongo
}

Un exemple d’utilisation de cette API est fourni dans le dossier frontend-ws (fichiers index.html et fichiers index.js).

Code d’erreurs

En cas d’erreurs de traitement, les codes de retour http sont utilisés voir et le corps de la réponse contient (en général) des objets json de la forme {name : "ErrorLabel", message : "Explicit message about error"}, avec les codes suivants :

Accès au serveur depuis l’extérieur du campus

Attention: le serveur est accessible depuis internet. Vous n’avez rien à faire de particulier