R3.01 - dev. web - côté client (vuejs)

2.1°/ La page principale.

• La page principale (i.e. App.vue) est découpée en deux colonnes principales.
• La colonne de gauche permet de gérer toutes les informations relatives aux personnages et contient un composant Team (fichier associé Team.vue)
• La colonne de droite permet de gérer toutes les informations relative aux villes, rues, boutiques, et contient un composant World (fichier associé World.vue).
• la façon de créer ces 2 colonnes est laissée libre : table, div, ... selon vos désirs.

2.2°/ Le composant Team

• Ce composant contient 2 sous-composants, organisés visuellement de haut en bas dans la colonne de gauche de la page principale :
  • PersoSelector
  • Perso

2.2.1°/ Le composant PersoSelector

• Ce composant permet de choisir le personnage courant.

2.2.2°/ Le composant Perso

• Ce composant permet d'afficher les caractéristiques (résumé + slots) du personne courant + les opérations possibles (achat, vente, affectation d'items, ...)
• Pour cela, il doit afficher :
  • un composant PersoCaracs qui affiche les caractéristiques du personnage courant (nom, niveau, vie, armure, or, etc.)
  • un composant PersoSlots qui affiche les slots du personnage, ainsi que la liste des objets achetés non assignés.
  • un composant PersoOps, qui gère les opérations possibles (achat, vente, ...)

2.3°/ Le composant World

• Ce composant contient 4 sous-composant, organisés visuellement de haut en bas dans la colonne de droite de la page principale :
  • TownSelector 
  • StreetSelector 
  • ShopSelector 
  • Shop

2.3.1°/ Le composant TownSelector

• Ce composant permet de choisir la ville courante.
• Au lancement de l'application, aucune ville courante n'est sélectionnée, ce qui implique que les composants StreetSelector, ShopSelector et Shop ne doivent pas être visibles.
• Quand une ville est sélectionnée, seul le composant StreetSelector doit être affiché, avec aucune rue sélectionnée.

2.3.2°/ Le composant StreetSelector

• Ce composant permet de choisir la rue courante dans la ville courante.
• Si aucune rue n'est sélectionnée, les composants ShopSelector et Shop ne doivent pas être visibles.
• Quand une rue est sélectionné, le composant ShopSelector doit être affiché, avec aucune boutique sélectionnée. Le composant Shop doit donc être invisible.

2.3.3°/ Le composant ShopSelector

• Ce composant permet de choisir la boutique courante dans la rue courante.
• Quand une boutique est sélectionné, le composant Shop doit être affiché.

2.3.4°/ Le composant Shop

• Ce composant est divisé en 2 colonnes, comme dans les TP 2 & 3.
• La colonne de gauche liste les objets (i.e. des instance d'Item) en stock, et celle de droite ceux sur commande.

3°/ Visuel

• La façon de représenter les différentes informations dans les composants est laissée libre, excepté les contraintes suivantes :
  • parmi les composants permettant de choisir quelque chose, il faut que vous utilisiez au moins 4 procédés différents de sélection : case à cocher, bouton radio, liste déroulante et champ de saisie. A vous de choisir quel type pour quel composant du moment que les 4 types sont utilisés.
  • pour les caractéristiques d'un personnage, vous devez utiliser au moins 3 procédés d'affichage : texte simple, texte dans champ de saisie, image.
  • pour les actions d'un personnage (achat, vente, ...), vous devez utiliser au moins 3 types d'éléments cliquable : bouton, texte, image.
  • certains composants ont des slots et/ou scoped-slots permettant de personnaliser une partie de leur apparence dans le composant parent (cf. section 5)

4°/ Organisation des données

• Comme dans les TPs précédents, il y a au moins 4 variables fondamentales :
  • la ville courante : currentTown,
  • le rue courante : currentStreet,
  • la boutique courante : currentShop,
  • le personnage courant : currentPerso.
• Il existe aussi des variables externes qu'il faut importer :
  • team : le tableau des personnages
  • towns : le tableau des villes

• Pour currentTown, currentStreet, currentShop, il est relativement logique de les mettre dans le composant World.
• En effet, quand l'utilisateur interagit dans TownSelector, StreetSelector, ShopSelector, il est facile d'émettre un événement qui sera capturé par World pour mettre à jour l'une de ces variables.
• Il est tout aussi aisé de passer ces variables (une ou plusieurs selon le composant) en props à ces composants.
• De même, il paraît logique d'importer le tableau towns.
• Pourtant, c'est dans App.vue qu'il faut absolument mettre toutes ces variables. L'explication est donnée en section 5.5 (ainsi que dans la dernière section du TD 4)

• En revanche, on peut mettre currentPerso dans le composant Team, sachant qu'il sera passé en props au composant Perso.
• On peut également importer le tableau team dans Team.

•  Chaque composant aura également besoin de variables locales (dans data, computed) et éventuellement d'autres props pour gérer son fonctionnement.
• A vous de décider lesquelles sont nécessaires et quelles sont celles qui vont dans data, celles qui vont dans computed et celles qui sont des props.

5°/ Organisation fonctionnelle.

• Globalement, les fonctionnalités sont les mêmes que dans le TP 3, à part les ajouts suivants QUI SONT OBLIGATOIRES :
  • on doit pouvoir choisir une ville,
  • dans les caractéristiques du personnage et quand on assigne un objet à un slot, il faut tenir compte des effets des objets affectés dans certains slots (cf. 5.5)
  • un personnage peut désassigner un objet d'un slot pour que cet objet se retrouve dans la liste des objets achetés  (cf. 5.6)
  • certains composant ont du contenu que l'on peut définir grâce à des slots et/ou scoped slots.

• Les sections ci-dessous décrivent des contraintes fonctionnelles particulières pour les composants.

5.1°/ TownSelector

Obligatoire :

• Cependant, il existe une contrainte fonctionnelle : TownSelector NE DOIT PAS recevoir en props le tableau towns, contenant les instances de Town, et donc également les rues, les boutiques.
• TownSelector doit donc avoir le volume minimum d'informations permettant de choisir une ville, par ex. juste un tableau avec les noms des villes.
• Pour ceux qui veulent aller au plus simple, une liste déroulante ou des boutons radio suffisent.

Optionnel

• Pour ceux qui voudraient avoir une interface "classe", vous pouvez essayer d'afficher une image façon carte géographique. Il faut ensuite cliquer sur le nom des villes pour les sélectionner.

5.2°/ StreetSelector

Obligatoire :

• Ce composant ne doit pas recevoir en props le tableau towns, ou encore le tableau streets de la ville courante.
• Il doit recevoir le volume minimum d'informations permettant de choisir une rue, par ex. un tableau contenant uniquement le nom des rues de la ville courante.

Optionnel :

• Vous pouvez ajouter d'autres informations qui seront affichées, comme par exemple, le nombre de boutiques dans chaque rue, le nombre d'objet proposés, ... A votre guise afin d'agrémenter le visuel.

5.3°/ ShopSelector

Obligatoire :

• Ce composant ne doit pas recevoir en props le tableau shops de la rue courante.
• Il doit recevoir le volume minimum d'informations permettant de choisir une boutique, par ex. un tableau contenant uniquement le nom des boutiques de la rue courante.

Optionnel :

• Vous pouvez ajouter d'autres informations qui seront affichées, comme par exemple, le nombre d'objets en stock, les catégories, ... A votre guise afin d'agrémenter le visuel.

5.4°/ Shop

Obligatoire :

• la façon dont s'affiche le nom de la boutique doit être personnalisable via un scoped-slot
• les titres de la liste des items en stock et sur commande doivent être personnalisables via un slot avec une valeur par défaut

 Optionnel :

• Si la boutique vend des items (en stock) de la catégorie food, mettre un timer en place et quand il est écoulé, les marchandises sont considérées comme pourries et donc retirée du stock.

5.5°/ PersoCaracs

Obligatoire :

• Certains items ont des effets sur l'armure, la vie ou la force d'un personnage.
• Les effets sont codés avec une lettre suivie d'un modificateur positif ou négatif :
  • a/A : modifie l'armure,
  • l : modifie la vie,
  • L : modifie la vitalité,
  • s/S : modifie la force.
• Quand la lettre est en majuscule, l'effet est permanent et sinon, il est temporaire. NB : l'application ne gère pas ce côté temporaire.
• Quand un item avec effet permanent est assigné à un slot, excepté le slot "bag", l'effet doit être pris en compte pour afficher l'armure/vie/force d'un personnage.
• Par exemple, s'il porte une armure avec effet A+10, et que sa caractéristique strength vaut 25, alors il faut afficher 35.

• Le façon d'afficher les éléments suivants doit être personnalisable via un scoped-slot :
  • niveau,
  • or.

5.6°/ PersoSlots

Obligatoire :

• la liste des objets non assignés doit apparaître dans ce composant
• les moyens d'assigner et désassigner un objet à un slot doit également se trouver dans ce composant.
• si on désassigne un objet avec effet, il faut que les caractéristiques du personnage soient recalculées

Optionnel :

• assigner et désassigner avec un drag and drop.
• objet avec un effet temporaire ne peut être affecté qu'au slot "bag".

5.7°/ PersoOps

Obligatoire :

• Avoir toutes les opérations présentes dans le TP 3 : achat, vente, commande, à réalisé de façon libre (comme dans le TP 3 ou bien avec d'autres systemes : cases à cocher, drag and drop, ...)

Remarque :

• La difficulté réside dans le fait que l'action est déclenchée dans PersoOps mais que cela doit impacter le contenu de PersoSlots et Shop, qui sont des composants "frère" ou "cousin".
• Par exemple, l'achat d'un objet doit modifier la liste des objets en stock de la boutique courante.
• Mais pour cela, il faut forcément que les données de la boutique courante soient stockées dans un composant parent commun à PersoOps et Shop, donc dans le cas présent, App.
• En effet, PersoOps va émettre un événement qui va être capturé par Team, qui va le réémettre à destination de App.
• Ensuite, App peut modifier les données de la boutique courante, ce qui permet de mettre à jour le contenu de Shop.
• C'est pourquoi l'importation du tableau towns (qui contient les villes qui contiennent les rue et les boutiques) doit se faire dans App et que les fonctions qui vont modifier la boutique courante seront également dans App.
• Cette organisation implique notamment que currentShop soit donnée en props à World, et ce que dernier la donne également en props à son composant fils Shop. Ce dernier peut ainsi afficher la liste des objets en stock/sur commande de la boutique courante et si ces listes sont modifiées par des fonctions dans App, ces changements seront répercutés au niveau de l'affichage dans Shop.

Optionnel :

• Lorsque la boutique courante vend des objets de catégorie "spell", il est possible de choisir un objet parmi ceux du slot "bag" ou ceux qui ne sont pas assignés et de le faire enchanter.
• Cependant, l'enchantement ne fonctionne que sur les objets avec aucun effet actuel.
• On doit pouvoir choisir entre un effet sur l'armure, la vie ou bien la force, dans tous les cas, de façon temporaire.
• On doit également choisir un niveau d'enchantement 1, 2 ou 3. Pour le niveau 1, l'effet aura un modificateur tiré aléatoirement entre +1 et +4, pour le niveau 2 entre +5 et +14, pour le niveau 3 entre +15 et +30.
• Le coût en or pour l'enchantement est de 100po pour le niveau 1, 1000po pour le niveau 2, et 10000po pour le niveau 3.

• Lorsque la boutique courante vend des objets de catégories "weapon" ou "armor", il est possible de choisir un objet de ces catégories parmi ceux qui ne sont pas assignés et tenter de l'améliorer.
• L'amélioration d'arme/armure suit le même principe que l'enchantement, excepté que cela fonctionne même sur les armes/armures ayant déjà un effet et qu'il y a une chance que l'amélioration soit en fait une détérioration, donc avec un modificateur d'effet négatif.
• Si l'amélioration est de niveau 1, il y a 5% de chance que cela conduise à une déterioration, 10% pour le niveau 2, et 20% pour le niveau 3.
• Si l'amélioration/détérioration concerne le même type, alors on additionne le modificateur actuel avec le modificateur issu de l'amélioration/détérioration,
• Sinon, on change l'effet de l'objet et on met le nouveau modificateur (idem pour les objets sans effets).

• Quand le personnage courant possède un objet (assigné ou non) qui n'est pas présent dans la boutique courante (ni en stock, ni sur commande), il est possible de l'ajouter dans la liste sur commande.
• Pour faire cet ajout, vous êtes libre du principe mais pouvez essayer le principe du menu contextuel.
• Quand on clique bouton droit sur un objet, s'il n'est effectivement pas présent dans la boutique courante, un menu contextuel apparaît,
• Ce menu n'a qu'une seule entrée, par exemple "ajouter à la boutique".
• Quand on clique sur cette entrée, cela provoque l'ajout dans la boutique.

• Quand on passe la souris sur un objet, son effet est affiché grâce à une infobulle.

5.8°/ fonctionnalités générales optionnelles

5.8.1°/ récupérer les données via une API

• Au lieu d'avoir les tableaux towns et team écrits dans model.js, on les crée grâce à des objets JSON reçus via une API.
• Pour accéder à cette API :
• l'URL principale : https://apidemo.iut-bm.univ-fcomte.fr/apidemo

IMPORTANT :

• Avant d'accéder à l'API via axios, utilisez votre navigateur qui vous sert à tester votre application vuejs et faîtes une requête à l'API.
• Par exemple, demandez https://apidemo.iut-bm.univ-fcomte.fr/apidemo/items/get.
• Votre navigateur ne va pas reconnaître les certificats du serveur et afficher un message d'erreur. Vous devez alors accepter les certificats et accepter les "risques".

• les routes possibles :
  • /items/get : permet de récupérer tous les items existants.
  • /persos/get : permet de récupérer les personnages existants.
  • /towns/get : permet de récupérer les villes existantes.
• ATTENTION : les identifiants des objets ont pour nom _id. Vous devez donc modifier model.js en conséquence.

5.8.2°/ graphisme

• Vous pouvez amélioré comme bon vous semble l'aspect graphique de l'application, notamment en utilisant du CSS ou bien des plugins JS tels que bootstrap.

5.8.3°/ autres

• Toute fonctionnalité non listée ci-dessus et restant dans l'esprit de l'application peut être implémentée.