Fil directeur du plan : chaque variable globale et chaque objet de données gagne un player_id (sentinelle PLAYER_SHARED='__shared__' par défaut partout — l'aperçu créateur et tous les tests existants continuent de fonctionner À L'IDENTIQUE, aucune signature appelée sans argument explicite ne change de comportement), plus un réglage per_player choisi une fois à la création : - per_player=1 (par défaut) : chaque joueur a sa propre valeur/ses propres lignes. - per_player=0 : valeur/lignes partagées par tous les joueurs (ex. un compteur de visiteurs global, un catalogue commun). db/global_vars/ : _global_variables passe de UNIQUE(name) à UNIQUE(name, player_id) — SQLite ne permet pas de modifier une contrainte UNIQUE via ALTER TABLE, reconstruction de la table détectée et faite une seule fois (ensure_global_vars_schema.py) pour les jeux créés avant cette phase. La ligne "modèle" (player_id=PLAYER_SHARED, créée par le créateur) porte le réglage per_player et sert de valeur PAR DÉFAUT : la première écriture d'un joueur sur une variable per_player crée paresseusement SA propre ligne (copiée depuis le modèle) ; une lecture sans ligne encore écrite retombe sur le modèle (nouveau resolve_player_key.py). list_global_variables() (tableau de bord) ne montre toujours que les lignes modèles ; nouveau list_global_variables_for_player() expose la valeur EFFECTIVE d'un joueur au runtime (full_game_payload.py). db/definitions/ + db/rows/ : chaque table d'objet généré (create_definition.py) gagne une colonne player_id (ADD COLUMN simple, pas de contrainte UNIQUE en jeu ici) ; _definitions gagne per_player. Contrairement aux variables, PAS de repli sur une ligne "modèle" pour les lignes d'un objet per_player — une LISTE n'a pas de valeur par défaut unique à copier comme un scalaire, un nouvel objet per_player démarre VIDE pour chaque joueur (nouveau resolve_row_player_key.py). get_row/update_row/update_row_field/delete_row filtrent aussi par player_id (pas seulement id) : garde-fou contre un row_id d'un AUTRE joueur, nécessaire dès qu'un objet per_player sera exposé sur la future route publique /jouer/<slug>. Migration : nouveau ensure_player_id_column(slug, table_name), appelé avant toute requête sur une table d'objet créée avant cette phase. Chaîne de rendu (screens/elements/list_elements.py -> screens/rendering/render_element_html.py -> render_repeater.py/ render_jauge.py/resolve_bound_row.py/visibility_condition.py/ filter_repeater_rows.py) : player_id transite dans le ctx déjà utilisé partout pour "champ en cours" (ctx["_forge_player_id"], même patron que ctx["_forge_play_mode"], posé une seule fois par list_elements quand enforce_visibility=True) — pas de nouveau paramètre positionnel à threader dans chaque fonction, juste une clé de plus dans un mécanisme déjà en place. Nouveau tests/test_player_state.py : verrouille à la fois le nouveau comportement (deux joueurs => valeurs/lignes indépendantes ; per_player=0 => partagé ; nouveau joueur => valeur par défaut pour une variable, liste VIDE pour un objet ; get_row ne fuite jamais vers un autre joueur) et la non-régression de l'aperçu créateur (comportement historique inchangé). Vérifié : 232 tests passent (9 nouveaux). Reste à faire (prochains commits) : route publique /jouer/<slug>, identité visiteur (cookie), bascule "Publier en ligne" dans le tableau de bord. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
61 lines
2.7 KiB
Python
61 lines
2.7 KiB
Python
import db
|
|
|
|
from .compute_operation import compute_new_value
|
|
|
|
|
|
def apply_data_action(slug, action, player_id=db.PLAYER_SHARED):
|
|
"""Exécute au moment du clic (mode jouable) une action "modifier_donnee" :
|
|
lit l'objet/la ligne/le champ visés dans l'action, calcule la nouvelle
|
|
valeur selon l'opération choisie, et l'enregistre — un vrai UPDATE SQL,
|
|
limité à cette seule colonne (les autres champs de la ligne ne sont pas
|
|
touchés). `player_id` (état par joueur, Phase 1) : la ligne visée doit
|
|
appartenir à CE joueur pour un objet per_player (voir get_row.py/
|
|
update_row_field.py — garde-fou contre un row_id d'un autre joueur)."""
|
|
definition_id = action.get("target_definition_id")
|
|
row_id = action.get("target_row_id")
|
|
field_name = action.get("target_field")
|
|
operation = action.get("data_operation")
|
|
raw_value = action.get("data_value")
|
|
if not (definition_id and row_id and field_name and operation):
|
|
return False
|
|
definition = db.get_definition(slug, definition_id)
|
|
if not definition:
|
|
return False
|
|
field_def = next((f for f in definition["fields"] if f["name"] == field_name), None)
|
|
if not field_def:
|
|
return False
|
|
row = db.get_row(slug, definition, row_id, player_id)
|
|
if not row:
|
|
return False
|
|
col = db.slugify(field_def["name"]).replace("-", "_")
|
|
if field_def["type"] == "relation":
|
|
col = col + "_id"
|
|
current = row.get(col)
|
|
|
|
try:
|
|
new_value = compute_new_value(operation, current, raw_value, field_def["type"] == "nombre_decimal")
|
|
except ValueError:
|
|
return False
|
|
|
|
new_value = _clamp_to_field_bounds(new_value, field_def)
|
|
db.update_row_field(slug, definition, row_id, field_def, new_value, player_id)
|
|
return True
|
|
|
|
|
|
def _clamp_to_field_bounds(value, field_def):
|
|
"""2.2 — bornage automatique : ramène la valeur dans [min_value,
|
|
max_value] si l'un ou l'autre est réglé sur ce champ, pour qu'une
|
|
jauge (voir render_jauge.py) ne puisse jamais dépasser 100 % ni
|
|
descendre sous 0 % (ou toute autre borne définie), quel que soit le
|
|
nombre d'actions "Augmenter de..."/"Diminuer de..." posées dans le
|
|
graphe de logique. Ne s'applique qu'aux champs numériques — un champ
|
|
non numérique n'a pas de min_value/max_value (voir create_definition)."""
|
|
if field_def["type"] not in ("nombre_entier", "nombre_decimal"):
|
|
return value
|
|
min_v, max_v = field_def.get("min_value"), field_def.get("max_value")
|
|
if min_v is not None and value < min_v:
|
|
value = min_v
|
|
if max_v is not None and value > max_v:
|
|
value = max_v
|
|
return value if field_def["type"] == "nombre_decimal" else int(value)
|