williamandClaude Sonnet 5
9776fbc057
Concept de premier ordre, distinct du système de variables globales — préalable identifié aux futurs exports SCORM/xAPI (note de cadrage .claude/Forge_Engine_Cadrage.pdf) : ces standards ont besoin d'un signal "score"/"terminé" propre, pas d'une convention sur une variable choisie par le créateur. - db/scoring/ (même patron que db/global_vars/) : table _scoring, un score numérique + un statut (non_commence/en_cours/termine/reussi/ echoue) par joueur (voir db.PLAYER_SHARED pour l'aperçu créateur). - Deux nouvelles actions de flux, dans les deux éditeurs (document et scène) : "Modifier le score" (réutilise le vocabulaire d'opérations déjà là pour "Modifier une variable" — incrémenter/définir/etc., aucune nouvelle colonne de nœud) et "Définir le statut de la partie". - Routes créateur (routes/flow/flow_node_run_score.py, flow_node_run_status.py) + miroirs publics par joueur (routes/public_play/) — même principe que flow_node_run_variable.py. - GET /game/<slug>/scoring/<player_id> : lecture interne, pas exposée au joueur, préparée pour être consommée par le futur export Web/SCORM. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
58 lines
2.6 KiB
Python
58 lines
2.6 KiB
Python
"""Constantes partagées de la couche données."""
|
|
|
|
import os
|
|
|
|
# Surchargeable via FORGE_PROJECTS_DIR (même schéma que
|
|
# auth/connection.py::FORGE_USERS_DB_PATH) — utilisé par le serveur
|
|
# joueur autonome (publish/player_app_template.py), qui pose cette
|
|
# variable AVANT d'importer db/ pour pointer vers son propre dossier
|
|
# "projects/" embarqué plutôt que celui, réel, du poste de développement.
|
|
# Résolu ici, à l'IMPORT (pas par un appel de fonction) : la variable
|
|
# d'environnement doit donc déjà être posée avant le tout premier
|
|
# `import db`.
|
|
PROJECTS_DIR = os.environ.get("FORGE_PROJECTS_DIR") or os.path.join(
|
|
os.path.dirname(os.path.dirname(os.path.abspath(__file__))), "projects"
|
|
)
|
|
|
|
# Types de champ exposés dans l'interface -> type de colonne SQLite réel.
|
|
FIELD_TYPES = {
|
|
"texte": {"label": "Texte court", "sql": "TEXT"},
|
|
"texte_long": {"label": "Texte long", "sql": "TEXT"},
|
|
"nombre_entier": {"label": "Nombre entier", "sql": "INTEGER"},
|
|
"nombre_decimal": {"label": "Nombre décimal", "sql": "REAL"},
|
|
"booleen": {"label": "Oui / Non", "sql": "INTEGER"},
|
|
"date": {"label": "Date", "sql": "TEXT"},
|
|
"relation": {"label": "Relation vers un autre objet", "sql": "INTEGER"},
|
|
}
|
|
|
|
# Types disponibles pour une variable globale (voir db/global_vars/) — un
|
|
# sous-ensemble de FIELD_TYPES : ni "relation" (une variable globale n'a pas
|
|
# d'objet à pointer) ni "texte_long"/"date" (pas gérés par
|
|
# apply_variable_action.py, qui ne coerce que ces 4 types). "objet"/
|
|
# "tableau" sont, eux, propres aux variables (pas de colonne SQL réelle,
|
|
# contrairement à un champ d'objet) : la valeur est stockée telle quelle
|
|
# (colonne TEXT) sous forme de JSON, lue via un chemin ".champ"/"[index]"
|
|
# (voir _resolve_variable_path dans screens/rendering/filter_repeater_rows.py).
|
|
GLOBAL_VARIABLE_TYPES = {
|
|
"texte": FIELD_TYPES["texte"],
|
|
"nombre_entier": FIELD_TYPES["nombre_entier"],
|
|
"nombre_decimal": FIELD_TYPES["nombre_decimal"],
|
|
"booleen": FIELD_TYPES["booleen"],
|
|
"objet": {"label": "Objet (JSON)"},
|
|
"tableau": {"label": "Tableau (JSON)"},
|
|
}
|
|
|
|
# Statuts de partie (voir db/scoring/) — préalable aux exports SCORM/xAPI,
|
|
# qui ont besoin d'un signal "terminé"/"réussi" propre plutôt que d'une
|
|
# convention sur une variable choisie par le créateur (voir le plan
|
|
# "Feuille de route produit"). "non_commence" est le défaut d'un joueur
|
|
# qui n'a encore rien écrit (voir db/scoring/get_score.py).
|
|
SCORE_STATUS_CHOICES = [
|
|
("non_commence", "Non commencée"),
|
|
("en_cours", "En cours"),
|
|
("termine", "Terminée"),
|
|
("reussi", "Réussie"),
|
|
("echoue", "Échouée"),
|
|
]
|
|
SCORE_STATUS_LABELS = dict(SCORE_STATUS_CHOICES)
|