Les laboratoires s'articulent autour du Projet Mirador. Ce projet affiche dans une application Java & JavaFX des données provenant de Internet (Services de données).
L'invitation GitHub Classroom est donnée en classe (elle est sous la diapo de titre de l'énoncé, dans la section commentaire).
On va créer 5 modèles pour l'application MIRADOR :
- Identifier les 5 modèles à partir de l'énoncé du projet OU à partir de ses propres choix de services
- Nommer les classes et les créer avec Eclipse
- Détailler les 5 modèles à partir des écrans et d'une discussion en classe
- Nommer les champs (au moins 5 champs par classe)
- Programmer les champs et générer les get/set
On va créer/adapter 5 vues pour l'application MIRADOR :
- Charger le projet Mirador existant
- Faire fonctionner son JavaFX dans Eclipse
- Rendre le projet versionnable dans GitHub (voir la fiche Commandes GitHub)
- Renommer les vues en fonction de son sujet
- Ajouter 5 fonctions publiques afficherTruc() à des vues existantes & les appeler (tout le reste est privé)
- Ajouter vos modèles en paramètres de fonctions & des données bidons à l'appel des fonctions, puis commit
- Coder l'affichage du modèle reçu vers le FXML
On va créer 5 DAOs pour l'application MIRADOR :
- Déterminer les données nécessaires selon l'écran designé (maquette, prototype)
- Identifier la source des données : indiquer l'url et le format du service de données, lister les champs
- Télécharger et parser les données : faire la preuve de concept à part, afficher en console (log) les données reçues et aussi les données parsées
- Encapsuler dans des DAO (un par modèle) : placer les codes de lecture dans une classe DAO pour que l'application s'en serve sans savoir d'où viennent vraiment les données
Critères de correction pour le code en général
- le code est appelé avant d'être implémenté, le pas à pas est toujours testé à chaque ligne
- l'évolution de la donnée est suivie avec des log qui affichent les valeurs (System.out.println ou Logger)
- chaque petit succès 🎉 est versionné commit & push, avec seulement le nouveau code testé, par exemple : « téléchargement json pokemon », « premier champs pokemon parsé »
Les critères d'évaluation sont : le respect de l'énoncé, le versionnement en temps utile et les commentaires de commits, le nommage selon les normes tout au long du processus, la séparation des couches de programmation, l'intégration des techniques vues en classe, le respect des livraisons intermédiaires.