lucas-c / rpg-bonhomme Goto Github PK

Message d'erreur poppant lors du rensignement d'un name="xxx" avec xxx n'existant pas en base de données.
C'est pas très joli tout ça ...

Il pourrait être cool d'ajouter un système de vérification des valeurs rentrées dans la fiche de perso.

Je pensais à l'ajout d'un fichier JS par jeu (un fichier CSS par jeu pour les champs, et un fichier JS comportant une méthode appellée à la validation pour checker nos totaux), regroupant les règles métiers de la génération de nouveaux persos low-level.
Etant donné que les règles sur les nouveaux peros lvl1 sont souvent les mêmes, On évitera bien sûr l'application d'un contrôle de champs sur des persos expérimentés ayant mis à niveau leurs compétences

https://github.com/Lucas-C/rpg-bonhomme/blob/master/layout/Les13Reliques.css

Ca pourrait être une idée de rajouter une homepage permettant un affichage globalisé des différents perso hébergé sur le serveur, avant une redirection vers la fiche en elle-même.

Ca permettrait de rendre tout ça un peu plus noob-proof, faire des tris (genre liste de perso par jeu), et rendre tout ça un peu plus propre (j'aime bien coller des URL forger avec mes mimines, mais bon ...).

Après ça dépends bien sur du niveau de finition souhaité sur l'ensemble.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update actions/cache action to v4
• Update actions/checkout action to v4
• Update actions/setup-python action to v5
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Proposal:

• on a successful PUT request to the WSGI DB, it will return a read-write secret key to the browser. This read-write secret-key is generated by HMAC-ing the base key (layout name + character sheet name) with a server-constant SALT.
• a read-only URL is provideded to the user by simply appending this secret key as a modification-key parameter to the base URL.
• for keys already present in the DB, the WSGI will only allow PUT modification if a secret-key parameter is provided and matches HMAC(base_key ^ SALT).

I prefer this approach over using two non-readable IDs, one for read-only access and one for read-write.

Cons:

• it adds a bit of API complexity : one more parameter for the JS & WSGI codes to handle.
• we still need a mandatory CSS #name input field

Moreover the WSGI now needs to handle to flavours of PUT requests : CREATE NEW (without secret key) & UPDATE (with secret key). But I cannot imagine a solution that wouldn't increase the WSGI API complexity.

Pros:

• it's relatively simple to understand for the end user : the concept of the secret key is easier to grasp and less confusing than using two opaque IDs
• this lets the character name be visible in the URL, which is very handy. The risk to stumble on a character by creating a character with the same name will still exists, but one will only access the read-only version by doing so.
• it's straightforward to implement (and doesn't require altering the DB schema for what it's worth)

Extrait d'un échange email avec Renaud Guezennec:

En gros, le fichier json de rolisteam est une base de données de personnages.
Il y a élements:

-La structure de la fiche de personnage: la liste des champs,(id, label, position, font, couleur de texte, type d'éléments (textfield, textarea, bouton, combobox) et d'autres. Le positionnement ne sert qu'à la génération du QML.

-Il y a le code QML (qui est la fiche de personnage visuelle), c'est un langague déclaratif proche du css (dans sa syntaxe). C'est bien pour créer une interface assez rapidement (qui est stocké dans le Json comme une valeur texte.

-Il y a la liste des personnages avec la valeur pour chaque champs. Genre si la structure définit le champs intelligence, à 3% en hauteur et 4% en partant de la gauche.
Chaque personnage à une clé intelligence, avec une valeur associé.

-Une liste d'images qui sert de fond aux fiches de personnages [facultatif aussi], les images sont un array de chaine de charactere, l'image est codé en base64 dans le fichier. Je prévois de gérer un lien hyper text en plus.

Le processus de création d'une fiche est assez simple:

L'utilisateur ouvre rcse (un programme appart de rolisteam: Rcse = Rolisteam character sheet editor), il drag/drop l'image de fond de sa fiche de personnage. Il positionne les différents champs sur l'image, quand c'est terminé, l'outil génère le QML (l'utilisateur est capable de le modifier s'il le souhaite). A cette étape le fichier ne contient que la structure.
Toujours dans RCSE (ou dans rolisteam), l'utilisateur (le mj dans rolisteam) peut ajouter des personnages et saisir les valeurs de champs.

Dans rolisteam, on charge le fichier json, on peut éventuellement ajouter des personnages.
Rolisteam ne lit que l'id du champs, le label. Il ignore tout l'aspect présentation.

Il récupère les images et le code QML et la structure. Il ouvre ainsi une sous-fenetre avec un onglet. Cet onglet affiche une tableview avec les différents champs et un personnage par colonne.

              Perso 1     Perso 2

Nom personnage: Dornthal Archaëlle.
Intelligence 8 14
...

Ensuite, le MJ peut affecter le personnage 1 au joueur Paul, et le perso 2 à Marie.

              Paul       Marie

Nom personnage: Dornthal Archaëlle.
Intelligence 8 14
....

Quand cette étape est faite, chez le joueur qui vient d'etre affecter à une fiche, s'ouvre une fenetre avec dans le premier onglet la tableview avec les noms des champs et la liste des valeurs pour son perso.
Dans un deuxieme onglet, s'ouvre la vue jolie de la fiche perso. Avec en fond, l'ilmage et les champs textes editables. Modifier une valeur dans la fiche provoque le changement sur le tableau et vis-versa.

Du coup dans cette organisation je ne sais pas si vous trouvez un endroit ou rpg-bonhomme peut aider. J'avais dans un premier temps pensait à proposer la génération de la structure de données, ou éventuellement la possibilité d'importer facilement des structures/styles.
Mais si je comprends bien, la partie visuelle est définie dans des styles qui ne sont pas générés par le systeme. Ils sont fournis par l'auteur de la fiche.

• public / private character ? -> listed or not in index
• checkbox for search engine referencement (meta noindex)
• header msg for character not found error
• header msg for readonly URLs
• help header to create new character in layouts
• better visual clues that operations are successful / failed