Retour de l'utilisateur sur le premier jet : "Déclencher un événement" ne doit JAMAIS faire choisir un élément — c'est une notification pure, rien de plus. C'est à l'ÉCOUTEUR (déclencheur "Sur un événement personnalisé" → condition → action) de décider quoi faire ensuite, avec ses réglages habituels (cible fixe, "Ligne cliquée"...), jamais à l'événement de transporter un paramètre. Retire donc tout le mécanisme de transmission ajouté au tour précédent (has_element_param, target_element_from_event, EVENT_ROW_ID, window.lastEventParams) : - db/custom_events/ : _custom_events perd sa colonne has_element_param — un événement n'est plus qu'un nom + une description. - screens/flow/ : retire target_element_from_event (colonne ajoutée par ALTER TABLE, laissée inerte sur les bases déjà migrées — sans conséquence, plus jamais lue ni écrite) et la constante EVENT_ROW_ID. - routes/flow/flow_node_run_data.py : retire la résolution EVENT_ROW_ID, revient à sa forme d'origine (seul CLICKED_ROW_ID reste géré). - templates/screen_edit.html : le nœud Action "Déclencher un événement" n'a plus qu'un sélecteur d'événement — plus de champs élément/ligne. Le nœud Action "Modifier un élément" perd la case "Utiliser l'élément transmis par l'événement en cours". L'onglet Événements perd la case à cocher "Paramètre" (création et édition). - templates/play.html : window.dispatchGameEvent(eventId) ne prend plus que l'id de l'événement — scan global inchangé, mais ne pose plus aucun window.lastEventParams. modifier_element et readFieldValue reviennent à leur résolution d'origine (plus de branche event-aware). 208 tests au total (2 tests retirés, devenus sans objet : la persistance de target_element_from_event et la résolution serveur d'EVENT_ROW_ID). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
90 lines
5.2 KiB
Python
90 lines
5.2 KiB
Python
# ---------- Logique visuelle (éditeur de flow à nœuds) ----------
|
|
#
|
|
# Remplace l'ancien système "Actions" attaché à chaque élément : toute la
|
|
# logique d'une scène (déclencheurs, conditions, actions) vit maintenant dans
|
|
# un graphe de nœuds propre à l'écran, visible dans le panneau "Logique de
|
|
# la scène" de l'éditeur (voir screen_edit.html) — un nœud Déclencheur
|
|
# ("Au clic sur X") relié à des nœuds Condition (deux sorties Vrai/Faux) et
|
|
# Action (les mêmes effets qu'avant : changer d'écran, modifier un élément,
|
|
# modifier une donnée). L'ancien système _actions reste en base pour ne rien
|
|
# casser sur les jeux déjà créés, mais n'est plus exposé dans l'éditeur ni
|
|
# utilisé par le mode jouable.
|
|
|
|
# Valeur sentinelle pour cond_row_id/target_row_id (nœud Condition/action
|
|
# "Modifier une donnée") : "la ligne de Répéteur sur laquelle on vient de
|
|
# cliquer", résolue au moment de l'exécution (window.lastClickedRowId côté
|
|
# client — voir play.html) plutôt que figée à la création du nœud. Utile
|
|
# quand le déclencheur est "Au clic" sur un Répéteur : la ligne cliquée
|
|
# n'est jamais connue à l'avance (chaque ligne du Répéteur exécute le MÊME
|
|
# graphe), donc choisir une ligne précise dans l'éditeur n'a pas de sens
|
|
# ici — -1 ne collisionne jamais avec un vrai id de ligne (toujours >= 1,
|
|
# AUTOINCREMENT SQLite).
|
|
CLICKED_ROW_ID = -1
|
|
|
|
TRIGGER_EVENTS = [
|
|
("clic", "Au clic"),
|
|
("soumission", "À la soumission"),
|
|
# 3.1 (Confort) — interactions au survol, reconstruit comme déclencheur
|
|
# de flow (au lieu d'un réglage statique dans le panneau de propriétés,
|
|
# voir universal_controls.py) : "survol" et "fin_survol" sont deux
|
|
# déclencheurs distincts et explicites (comme "Au clic"), sans effet
|
|
# implicite — un créateur qui veut qu'un texte affiché au survol
|
|
# disparaisse ensuite doit poser l'action inverse sur "Fin du survol"
|
|
# lui-même, plutôt que de compter sur un retour automatique.
|
|
("survol", "Au survol"),
|
|
("fin_survol", "Fin du survol"),
|
|
# Pas de "trigger_element_id" pour celui-ci : il concerne l'ÉCRAN entier,
|
|
# pas un élément précis (voir 1.2 dans claude/forge-engine-lacunes-boitemail.md
|
|
# côté projet Forge — "affichage piloté par la donnée"). Se déclenche
|
|
# côté jouable à chaque fois que l'écran est montré (premier affichage,
|
|
# retour en arrière, changement d'écran...) ET après toute donnée
|
|
# modifiée pendant qu'on est déjà sur cet écran — ce qui permet de
|
|
# cacher/montrer un élément selon l'état de la partie SANS qu'un clic
|
|
# explicite soit nécessaire pour le réévaluer.
|
|
("affichage", "À l'affichage de l'écran"),
|
|
# Écoute un événement personnalisé (voir screens/custom_events/),
|
|
# déclenché depuis N'IMPORTE QUEL autre graphe (une autre scène, un
|
|
# autre modèle) via l'action "declencher_evenement" — ni élément ni
|
|
# écran précis : trigger_custom_event_id (quel événement) est le seul
|
|
# réglage propre à ce nœud, retrouvé par un scan global de
|
|
# gameData.flows côté client (voir dispatchGameEvent() dans
|
|
# templates/play.html), au même titre que findTriggerNode().
|
|
("evenement", "Sur un événement personnalisé"),
|
|
]
|
|
|
|
CONDITION_OPERATORS = [
|
|
("egal", "est égal à"),
|
|
("different", "est différent de"),
|
|
("superieur", "est supérieur à"),
|
|
("inferieur", "est inférieur à"),
|
|
("superieur_egal", "est supérieur ou égal à"),
|
|
("inferieur_egal", "est inférieur ou égal à"),
|
|
]
|
|
CONDITION_OPERATOR_LABELS = dict(CONDITION_OPERATORS)
|
|
|
|
FLOW_NODE_FIELDS = {
|
|
"trigger_element_id", "trigger_event",
|
|
"cond_definition_id", "cond_row_id", "cond_field", "cond_field_type", "cond_operator", "cond_value",
|
|
# 2.4 — conditions combinées (ET/OU) : cond_clauses est une liste JSON de
|
|
# clauses supplémentaires (en plus de la clause "historique" ci-dessus,
|
|
# qui reste la première clause) + cond_combinator ('et'/'ou') pour savoir
|
|
# comment les combiner. Absents => comportement legacy (une seule clause).
|
|
"cond_clauses", "cond_combinator",
|
|
# Condition sur une VARIABLE GLOBALE plutôt qu'un champ d'objet — voir
|
|
# ensure_flow_schema.py pour le détail des 3 clés (cond_source vaut
|
|
# "objet" ou "variable" ; absent => "objet", comportement historique).
|
|
"cond_source", "cond_variable", "cond_variable_chemin",
|
|
"action_type", "target_screen_id", "target_element_id", "element_property", "element_value",
|
|
"target_definition_id", "target_row_id", "target_field", "data_operation", "data_value",
|
|
"target_variable",
|
|
# Événements personnalisés (voir screens/custom_events/) : quel
|
|
# événement un nœud Déclencheur écoute (trigger_event="evenement") ou
|
|
# un nœud Action déclenche (action_type="declencher_evenement") — un
|
|
# événement est une pure NOTIFICATION, sans paramètre : "déclencher"
|
|
# ne fait que signaler, jamais choisir un élément. C'est à l'ÉCOUTEUR
|
|
# (déclencheur → condition → action) de décider quoi faire ensuite,
|
|
# avec ses propres réglages habituels (target_element_id normal, pas
|
|
# de mécanisme dynamique dédié).
|
|
"trigger_custom_event_id", "target_custom_event_id",
|
|
}
|