Laboratoire du cours GTI525 (GTI525-Lab-EQ01-01)
Developer intrigued by web development and distributed systems. Skilled in both frontend and backend tech. Enjoys delving into distributed computing and building creative projects at the intersection of web and systems.
Vous devez implémenter aussi la ressource pointsdinteret dans l’API REST, ce qui permettra autant de consulter les points d’intérêts pertinents aux cyclistes (des fontaines à boire et des ateliers de réparation vélo) que d’ajouter un nouveau point d’intérêt. Le point de terminaison et les paramètres sont décrits ci-dessous :
Point de terminaison pointsdinteret
Identifiant :id pour consulter les détails d’un point d'intérêt donné (optionnel).
Paramètre limite pour limiter le nombre de points fournis dans la réponse (optionnel).
Paramètre type pour retourner les points d'intérêt d’un certain type.
Paramètre nom pour retourner les points d'intérêt qui contiennent la chaîne de caractères fournie dans leur nom. Vous pouvez utiliser des expressions régulières si vous le souhaitez (optionnel).
Vous devez ajouter sur la carte des marqueurs correspondants à tous les compteurs disponibles. Le marqueur correspondant à celui dont l’icône l’utilisateur a cliqué dessus sur la vue comptage de vélos (marqueur cible) doit avoir une couleur différente de celles des autres
Problème
Le bouton points d'intérêt affiche les fontaines et il ne devrait pas
Résultat désiré:
Afficher les fontaines en cliquant sur le bouton fontaine à boire
La carte doit être initialement centrée pour afficher l'ensemble des compteurs disponibles. Vous devez utiliser les coordonnés de la Ville de Montréal et celles des compteurs pour calculer le centre de la carte et le zoom nécessaire pour afficher tous les marqueurs.
Vous devez réusiner le comportement de la ressource compteurs. Une requête pour obtenir le contenu du chemin gti525/v1/compteurs doit renvoyer un JSON qui contient la liste des compteurs avec les informations nécessaires pour remplir la vue que vous avez implémentée dans la première phase du laboratoire et pour laquelle les données ont probablement été codées dans un fichier JavaScript (ID, nom du compteur, statut, année d'implantation, etc) - voir Annexe 1.
Le chemin pour accéder aux ressources compteurs:
Le mot-clé compteurs.
Paramètre limite pour limiter le nombre d’entrées fournies dans la réponse (optionnel).
Exemple : /gti525/v1/compteurs?limite=10
Pour cette tâche vous allez probablement réusiner votre implémentation proposée pour la deuxième phase du projet. Une requête pour le chemin compteurs/:id (où id est l’identifiant d’un compteur) doit retourner les informations sur compteur (celui identifié par id), mais pas le nombre des passages enregistrés. Ce comportement est décrit dans la tâche suivante.
Exemple : /gti525/v1/compteurs/100041114
Vous devez implémenter une première version de l’API. Pour ce livrable, vous n’avez pas besoin d'implémenter toutes les fonctionnalités de recherche. Pour un compteur recherché, votre API pourra fournir toutes les données disponibles sans considérer les paramètres de recherche pour la période. L'implémentation correcte des fonctionnalités de recherche sera toutefois un requis du livrable 3.
Le point d’accès (endpoint) de l’API devra être composé par :
Exemple : http://localhost:8080/gti525/v1/compteurs/100054585?debut=20200101&fin=20200131
Vous devez créer l'élément (div ou autre) dans l’application frontale qui contiendra le formulaire qui permettra aux utilisateurs d’ajouter un nouveau point d'intérêt. Le formulaire permettra aux utilisateurs d'ajouter une nouvelle fontaine à boire ou un atelier de réparation vélo. L’Annexe 2 vous donne un exemple de formulaire. Quelques informations peuvent ne pas être pertinentes aux deux types de points d'intérêt. Par exemple, pour les ateliers, l'adresse peut être suffisante pour trouver leur géolocalisation. Les fontaines à boire, par contre, sont généralement placées dans des parcs ou lieux publics, et l’adresse du parc n’est pas souvent suffisante pour les localiser. Vous devez afficher les champs pertinents au type de point d'intérêt choisi par l'utilisateur.
Vous devez créer des tableaux ou équivalents (le terme dépend de votre choix de base de données), pour stocker les données des fichiers d’entrées fournis avec l’énoncé du livrable 1 ; c.-à-d., les informations sur les compteurs et sur les fontaines à boire. Votre conception doit permettre aux utilisateurs d’ajouter un nouveau point d’intérêt, tel qu’une nouvelle fontaine à boire ou un atelier de réparation vélo.
Comme partie de votre application dorsale, vous devez intégrer les fichiers fournis avec cet énoncé pour créer une API qui répondra aux requêtes AJAX provenant du front-end. Le choix du mécanisme utilisé pour le stockage des données ne sera pas pris en compte lors de ce livrable. Vous pouvez utiliser une base de données ou des fichiers textes.
Vous aurez à implémenter une application dorsale qui acceptera des requêtes de type AJAX de l'usager pour satisfaire aux exigences T3.* et T4.*. Votre back-end devra donc démarrer un serveur web qui acceptera des requêtes AJAX en provenance du code côté client.
Notes:
Plus tard dans la session, nous aurons un cours sur Node.JS. Vous êtes toutefois libres d'utiliser le langage et/ou cadriciel de votre choix pour le back-end.
Pour ce livrable, il n'y a pas d'exigences spécifiques au niveau du back-end autres que celles visant à fournir les fonctionnalités demandées. Toutefois, au livrable 3, votre back-end devra exposer les fonctionnalités sous forme d'APIs REST. Cette information peut donc possiblement aider à orienter votre conception, bien que cet aspect ne soit pas évalué au livrable 2.
Vous devez intégrer l'accès aux fichiers compteurs_stats_[année].csv au back-end pour répondre aux requêtes AJAX du front-end sur les statistiques de comptages vélos. Il n'est pas nécessaire d'intégrer l'accès aux fichiers du livrable 1 au back-end; cela sera toutefois un requis du livrable 3. En d’autres mots, les propriétés des compteurs (ex. latitude, longitude, nom, etc) peuvent être intégrées dans le code du front-end.
Vous devez ajouter une modale (overlay) qui apparaîtra lorsque l’utilisateur cliquera sur un des icônes 📍 de la vue comptage de vélos créé pendant la première phase du projet. Cette couche modale permettra aux utilisateurs d'accéder à la vue des compteurs sous forme cartographique. Vous devez utiliser les coordonnées géographiques des compteurs disponibles dans le fichier compteurs.csv fourni lors de la première phase du projet.
Note: Vous pouvez utiliser les éléments de votre choix pour créer la couche modale qui contiendra la carte (ex. <div>). Toutefois, vous ne devez pas utiliser une nouvelle fenêtre ou onglet du navigateur pour cette finalité.
Pour consulter le nombre de passages enregistrés par un compteur pendant une certaine période, vous allez implémenter le chemin compteurs/:id/passages. Le point de terminaison et les paramètres sont décrits ci-dessous :
Chemin compteurs/:id/passages
Paramètres de début et fin de la période recherchée (début et fin).
Paramètre limite pour limiter le nombre d’entrées fournies dans la réponse (optionnel).
Exemple : /gti525/v1/compteurs/100041114/passages?debut=20200101&fin=20200131&limite=10
En quelque sorte liée aux tâches T2.1 et T2.2, cette tâche consiste à bien utiliser les fonctionnalités disponibles dans la base de données. Autant que possible, les fonctionnalités de recherche fournies par l’API REST doivent s'appuyer sur les moyens fournis par la base de données que vous utilisez. Vous devez donc éviter de faire le filtrage des données via JavaScript car cela sera pris en compte dans l’évaluation.
Il devra être possible d'accéder à l'application web au moyen de l'application dorsale, c'est-à-dire via une URL servie par votre serveur web (par exemple, http://localhost:8080/). Votre serveur web devra servir l'ensemble des ressources demandées (ex., HTML, CSS, JS, images, etc.).
Également à ce que vous avez implémenté pour les capteurs dans la deuxième étape du projet, vous devez ajouter la fonctionnalité qui permet d’afficher un point d'intérêt sur une carte. Mais différemment du cas des compteurs, vous n’avez qu’à afficher un seul point d'intérêt à la fois sur la carte. L’Annexe 3 vous donne un exemple de cette fonctionnalité. Dans la vue des fontaines à boire/ateliers réparation, lorsque l’utilisateur clique sur l’icône 📍 associée avec un point d'intérêt, ce dernier doit être sélectionné sur la liste, et la carte doit afficher un marqueur qui correspond au point choisi.
Tous les marqueurs doivent contenir des indices contextuels (pop-up hints). Lorsque l’utilisateur clique sur un des marqueurs, un indice contextuel qui contient le nom du compteur doit s’afficher. L’indice pour le marqueur cible doit être affiché par défaut lorsque la couche modale apparaît.
T1.1: Dans le deuxième livrable, vous avez commencé à implémenter une API REST pour servir les informations des passages vélos. Nous allons garder le même point de terminaison (endpoint) racine, mais le comportement de l’API changera légèrement. Pour rappel, le point de terminaison racine de l’API est composé par :
Le nom d'hôte
Le code gti525
La version de l'API
Exemple : http://localhost:8080/gti525/v1/
Lorsqu’une requête GET est lancée au point de terminaison racine, votre API doit fournir un JSON qui contient tous les points de terminaison des ressources servies par l’API REST (par ex., les points de terminaison pour les ressources compteurs et pour les points d'intérêt).
Pour l'implémentation de l’API REST de ce projet, vous n’êtes pas obligés de gérer des jetons pour authentifier et pour autoriser les actions des utilisateurs. Les requêtes aux points de terminaisons de l’API n’ont pas besoin d’être authentifiées en utilisant des jetons envoyés dans les en-têtes des requêtes HTTP. Toutefois, dans des conditions réelles, votre application devrait fournir un niveau minimal de sécurité, et seulement les utilisateurs qui détiennent un jeton pourraient entreprendre certaines actions. Des points supplémentaires vous seront attribués si telle fonctionnalité est présente dans votre implémentation.
Pour cette tâche vous devez implémenter un système pour autoriser ou refuser certaines actions des utilisateurs. Vous devez implémenter une fonctionnalité pour générer des jetons qui seront utilisés par l’API REST pour autoriser des actions des utilisateurs. Lorsqu’un utilisateur émet une requête HTTP pour accéder à une fonctionnalité de l’API REST, l’utilisateur doit fournir son jeton pour que l’action soit autorisée. Une action sans un jeton valable doit donc être refusée par l’API.
Vous devez ajouter une option qui permet à l’utilisateur de choisir l’échelle du graphique (jours, semaines, mois). Pour ce livrable, vous n’avez qu’à afficher le graphique à l’échelle des jours; le choix d’échelle sera toutefois un requis du livrable 3.
Notes: Nous recommandons l’usage des bibliothèques telles que Chart.js pour produire un graphique simple (barres, lignes, aire), mais vous êtes libres d'utiliser la bibliothèque de votre choix.
Le backend est un projet à part entière et donc devrait avoir sa propre documentation dans laquelle se trouve les commandes de base pour démarrer l’application, migrer la base de données et exécuter les seeds pour l’insertion de données.
Vous devez ajouter une option qui permet à l’utilisateur de choisir l’échelle du graphique (jours, semaines, mois). Pour ce livrable, vous n’avez qu’à afficher le graphique à l’échelle des jours; le choix d’échelle sera toutefois un requis du livrable 3.
La vue Statistiques des comptages vélos devra s’afficher lorsque l’utilisateur cliquera sur l’un des liens/buttons Statistiques d’un compteur, et que l’utilisateur saisit les dates de recherche souhaités (vue conçue lors du livrable 1). Vous devez inclure un bouton de retour vers l’arrière. Si ce bouton est cliqué, la “Comptages de vélos” est affiché.
Pour cette tâche, il faut créer un ou plusieurs tableau(x) ou équivalent(s) pour stocker les données fournies avec l’énoncé du livrable 2 ; c.-à-d., les informations des passages de vélos enregistrés pour chaque compteur.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.
