[CO] Applications, APIs, Compendiums, etc... 6

Ce sujet pour que les rôlistes qui sont développeurs dans le civil puissent échanger autour de leurs créations informatiques liées à Chroniques Oubliées.

Merci !

Je reprends ton message du fil ressources ici.

Salut

Merci pour tes remarques, mais :

• Personne n'a jamais dit qu'une clef primaire devait forcément être une clef technique sous forme d'entier qui s'incrémente tout seul à chaque insertion. Quand j'ai commencé il y a 30 ans, il n'y avait pas de SGBDR qui faisait le boulot, tu choisissais une clef primaire parmi les clefs candidates de ton fichier et en général c'était une clef sémantique (un code client, un no de compte comptable, etc -- et oui, on travaillait presque toujours avec des système de fichiers ISAM). Je me suis construit un petit back-end en PHP pour alimenter la base MySQL exploitée par l'API, mais je n'ai pas tout codé, il m'arrive de faire des INSERT à la main parce que je vais plus vite comme ça, et c'est plus simple pour ma pauvre cervelle fatiguée de manipuler un slug de type 'epee-deux-mains' plutôt que '123' ou '000102030405060708090a0b0c0d0e0f'

Sans vouloir rentrer dans le débat d'expert: si. Je te laisse lire cet article et celui-ci. Dans le pire des cas le SGBD et les programnes utilisateurs doivent connaître la forme de la clé, les clés que tu utilise sont de longueurs variable, avec des caractères spéciaux (sujet à l'encoding) placés à des endroits non prévisibles.

• Pourquoi mettre un tableau d'objet ? Un équipement est dans une catégorie et une seule dans ma BD (je n'ai pas vu la même arme ou la même armure dans plusieurs tableaux différents dans les règles de CO). Je modélise ce qui existe.

Fair enough. Je pensais plutôt à la "futur-proofitude"

• Pourquoi les propriétés sont sous cette forme ? Parce que le flux retourné est la conversion en JSON du resultset d'une requête SQL, dans laquelle je fais un group by et un group_concat().

Je n'ai pas ton schéma en tête mais du coup dans la base c'est stocké comment ? tu as, par exemple un champs propriété (de type VARCHAR(3)) et un champs valeur (probablement INT) que tu groupe ou tout est sous forme de chaines ? La façon dont tu extrait les données ne conditionne pas nécessairement le format de sortit. Je ne sais pas si tu connais Swagger (OpenAPI) mais c'est très pratique pour contractualiser l'API entre le front et le back end.

Je sais que cette API n'est peut-être pas tip top moumoute, mais déjà elle a le mérite d'exister parce que je suis allé au-delà du "j'y ai pensé mais j'ai rien commencé". De plus je l'ai construite au départ pour répondre à mon application cliente Chroniques Mobiles qui pour l'instant fait un .split() sur les quelques champs qui le nécessitent.

Maintenant, si tu connais le moyen de créer des flux JSON plus structurés (avec des champs qui sont des objets ou des tableaux d'objet comme tu le souhaites) à partir d'une simple requête SQL, je suis preneur. Je n'ai pas commencé à creuser les pistes d'amélioration, mais si tu as la connaissance et que tu souhaites la partager, n'hésites pas (en MP pour que ce forum ne tourne pas au cours d'informatique).

Si tu préfères ignorer mon API et construire la tienne, libre à toi. Je peux te fournir la BD si tu en as besoin.

Bon la c'est la partie qui me gêne : je t'ai fais des retours que tu demandais, dans la plus pur tradition Open Source, je ne pense pas que mes retours étaient infondés ou aggressif mais tu semble mal le prendre. Ce n'est pas comme cela que je vois la collaboration autour de projets communs.

Je n'ai jamais dis que je ne souhaitais pas l'utiliser ou que c'était mauvais (voir la dernière ligne de mon message). Il me semble qu'une réponse constructive serait plus autour de : "tes retours sont censés, j'accepte les PR sur Github, faisons de cette API l'API de référence pour CO !".

Bien à toi

Stéphane

De même.

Arnaud.

Hello

Pour l'anecdote, mes clefs primaires sont générées par un petit algo côté client (du javascript dans mon backend d'alimentation de la base) qui transforme les libellés / désignation en slugs (comme pour un blog), en mettant en minuscules et en retirant tous les accents, caractères spéciaux, diacritiques, apostrophes, etc... Il ne peut donc y avoir que des lettres minuscules, des chiffres et des tirets dans mes clefs. Si c'est bon pour Wordpress, c'est bon pour comob

Sur la futur-proofitude, encore une fois, je me limite à ce qui existe. Jamais bon, l'over-engineering.

J'ai une table de toutes les propriétés d'équipement possibles (DM, DEF, Portée, Plage de critique, etc..). J'ai une table d'association où chaque équipement est lié avec une ou plusieurs propriétés (celles-ci dependent de la catégorie d'équipement, pour une arme ce sont ses DM qui nous intéressent et éventuellement sa portée, pour une armure son bonus de DEF), et la valeur correspondante. Je fais donc un join et un group by pour lister les propriétés d'un équipement. Tout est en string (l'id d'equipement, l'id de propriété et la valeur), je n'allais pas refaire une database dans la database, j'ai fait un truc générique.

J'ai déjà eu l'occasion de mater des tutos divers qui utilisaient swagger, jamais de le mettre en œuvre. Je jetterai un cil à l'occasion.

J'avais demandé un retour à cofbazar sur ce que je lui avais bricolé. Une lecture de mes posts précédents te renverra vers d'autres sections du forum où se trouvent des liens vers mon Github (cf aussi mon dernier MP) et vers un diagramme de la BD en ligne.

Bien à toi

top 👍

Bonjour,

Merci pour l'ajout !

Je pense que je vais m'en servir pour ajouter un nouveau filtre pour rechercher uniquement les objets utilisables par tel ou tel profil (par contre, pour l'instant comme je l'avait dit, ce n'est pas ma priorité).

Je continue de donner quelques info sur ce que je fais, au cas ou ça peut aider.

Mon but, avec l'application cof bazar, c'est de générer pour chaque objet d'équipement une carte au format micro-euro (32x45 : https://www.makeplayingcards.com/design/custom-micro-size-cards.html) (un exemple du travail en cours est dispo ici : https://cofbazar.github.io/ressources/cards-v2.0.pdf). Ensuite, je souhaite faire une fiche de perso A4 qui permet de positionner ces cartes autour du perso, comme pour les RPG PC (je fais ça principalement pour mes enfants, car j'ai remarqué qu'il adoraient les cartes lorsque l'on joue à des jeux)

Techniquement, pour la partie génération d'objet, c'est un script python, qui parse le site du DRS et extrait un max d'info. Ensuite, j'enrichie ces info avec de la donnée que j'ajoute à la main (addons) pour chaque équipement de base. Ensuite, je définie des saveurs (flavors) qui me permettent de générer des objets dérivés en leur appliquant des modification (par exemple : Epée a 2 main, de feu)

Le tout est en json, car j'adore ce format de fichier, et il est très facile à utiliser que ce soit en python ou en javascript.

Pour la partie affichage des objets, c'est du vue-js/javascript directement dans le navigateur, pas de serveur node ou autre.

L'avantage du json, c'est que il est facile d'ajouter des nouveaux champs quand j'en ai besoin et vu que je construit ce qu'il me faut pour mes cartes petit a petit, c'est parfait.

Voila, si vous souhaitez que je partage également mes scripts python c'est possible, mais j'avoue que c'est assez mal ecrit, car a priori, une fois les objets générés , je ne devrait plus en avoir besoin.

N'hésitez pas a commenter, proposer, je suis ouvert à toute proposition, seul mon temps est limité pour les réaliser

a+

Christophe

PS : Un exemple d'addon et de saveur et des 2 cartes correspondantes :