Dev #2
Assignees
w-vandal (Vandal William)
Clear assignees
w-vandal (Vandal William)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Forge-Store/Forge-Engine#2
Reference in New Issue
Block a user
Régression introduite par le commit précédent (préservation de l'état visuel transitoire dans applyOpenRowBindings) : la restauration du dataset complet d'un nœud copiait aussi clickBound/hoverBound/ hoverTriggerBound — des indicateurs INTERNES au moteur (voir bindClicks/ bindHoverTexts/bindHoverTriggers), jamais un état posé par une action "Modifier un élément". Un nœud tout juste régénéré se retrouvait donc marqué "déjà lié" à tort, alors qu'aucun écouteur de clic n'y était réellement rattaché : bindClicks() le voyait déjà "bound" et sautait son rattachement, rendant l'élément silencieusement inerte pour le reste de la partie. Symptôme rapporté : dans un écran avec un Répéteur ET un panneau de détail utilisant des {{champ}}, le premier clic sur une ligne fonctionne (exécuté par les gestionnaires posés au chargement de la page), mais plus aucun clic ne répond ensuite sur AUCUNE ligne — le Répéteur étant regénéré dans le même sous-arbre que le panneau de détail (ancêtre commun avec des {{champ}} non résolus), donc concerné par la même restauration de dataset. Fix : exclure ces trois clés internes de la sauvegarde/restauration — seul l'état réellement transitoire (style inline, classes, data-toggle-* posés par "Modifier un élément") doit survivre à la regénération. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>Root cause enfin identifiée grâce à un log console instrumenté par l'utilisateur (indispensable — sans lui les précédents correctifs visaient le mauvais chemin de code, refreshRuntimeData(), qui ne se déclenchait même pas dans ce scénario) : l'action "Ouvrir la ligne cliquée" (ouvrir_ligne) appelle applyOpenRowBindings() DIRECTEMENT, sans jamais rappeler bindClicks() ensuite — contrairement à refreshRuntimeData(), qui elle le fait déjà correctement. Si l'écran a un Répéteur ET un panneau de détail (avec des {{champ}}) posés dans un même conteneur parent, applyOpenRowBindings() régénère tout ce sous-arbre — Répéteur compris — pour résoudre les {{champ}} du panneau. Les lignes du Répéteur héritent alors de nœuds DOM tout neufs, sans le moindre écouteur de clic (le garde-fou anti-doublon de bindClicks() repose sur dataset.clickBound, absent sur un nœud neuf, mais bindClicks() lui-même n'était jamais rappelé pour les attacher). Symptôme exact reproduit : le tout premier clic sur une ligne fonctionne (gestionnaires posés au chargement de la page), plus AUCUN clic ne répond ensuite sur AUCUNE ligne, sans erreur console — confirmé par un log montrant runFlowFrom() jamais réinvoqué au clic suivant, et manuellement réparé en rappelant bindClicks() à la main dans la console. Fix : bindClicks()/bindHoverTexts()/bindHoverTriggers() sont maintenant rappelés juste après applyOpenRowBindings() dans le gestionnaire de "Ouvrir la ligne cliquée", comme ils le sont déjà dans refreshRuntimeData(). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>Cause du "rechargement" perçu par l'utilisateur (et du flash à vide sur la ligne de Répéteur juste cliquée, visible sur une vidéo de repro) : applyOpenRowBindings() ne pouvait cibler que les éléments de PREMIER NIVEAU de l'écran (seuls eux ont un wrapper .playElement dans le DOM). Sur cet écran, "mail content" est niché à 2 conteneurs de profondeur, et le SEUL élément de premier niveau est le conteneur racine de tout l'écran — donc chaque clic sur une ligne de Répéteur régénérait littéralement tout l'écran (jauges, onglets, Répéteur compris) pour ne mettre à jour qu'un seul panneau de détail, avec un flash à vide pendant la reconstruction. Fix : applyOpenRowBindings() cible maintenant directement, à n'importe quel niveau d'imbrication, le(s) élément(s) qui portent réellement un {{champ}} non résolu (repéré via document.querySelector ('[data-element-id=...]'), disponible sur CHAQUE élément rendu, pas seulement les élément de premier niveau) — et seulement les plus "hauts" parmi eux, pour ne jamais régénérer un même nœud deux fois. Seul "mail content" est donc désormais remplacé (via replaceWith), sans toucher au Répéteur ni au reste de l'écran. La sauvegarde/restauration de l'état visuel transitoire (style, classes, dataset hors clickBound/hoverBound/ hoverTriggerBound) suit le même principe, appliquée au nœud remplacé et à ses descendants. Aucun aller-retour réseau n'a jamais eu lieu ici (refreshRuntimeData() utilise déjà fetch/JSON, pas de navigation de page) — la sensation de rechargement venait uniquement de la granularité du remplacement DOM, pas d'un manque d'AJAX. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>L'utilisateur a raison de pointer que le vrai souci n'était pas un bug isolé mais l'APPROCHE elle-même : detruire puis reconstruire un nœud du DOM à chaque clic (même bien ciblé, comme depuis les 2 derniers commits) cause toujours un flash visuel, puisque tout état transitoire du sous-arbre (visibilité posée par "Modifier un élément", focus...) est perdu et reconstruit à neuf. C'est ce qui donnait l'impression trompeuse d'un "rechargement" — un comportement JS parfaitement normal quand on manipule le DOM ainsi, mais évitable : c'est exactement le problème que la réconciliation ciblée de React (ne patcher que ce qui a changé, jamais recréer un nœud pour rien) résout côté framework. applyOpenRowBindings() ne remplace donc plus JAMAIS le nœud de l'élément ciblé (ex. "mail content") — il patche directement, en place : - un nœud TEXTE contenant {{champ}} est coupé en 3 (texte avant, un <span data-bind-field="champ">, texte après) LA PREMIÈRE FOIS SEULEMENT ; toute ouverture suivante se contente de changer le textContent de ce span — plus aucune reconstruction ensuite. - un ATTRIBUT contenant {{champ}} (ex. href="{{link_real_url}}") voit son gabarit d'origine mémorisé sur data-bind-attr-<nom> au premier passage, pour être recalculé et réécrit directement à chaque fois sans jamais reconstruire le nœud. Plus aucun nœud n'étant détruit, la sauvegarde/restauration de l'état visuel transitoire (ajoutée dans un commit précédent pour compenser cette destruction) devient inutile et est retirée. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>Jusqu'ici, la logique (déclencheurs Au clic/Au survol/Fin du survol) et les animations posées dans l'éditeur de l'écran-MODÈLE d'un élément de jeu réutilisable (ex. "mail content") sur SES PROPRES enfants ne s'exécutaient jamais quand cet élément était simplement posé sur une autre scène : findTriggerNode() cherchait bien le déclencheur dans tous les écrans (modèles compris) mais runFlowFrom() n'exécutait ensuite le graphe que dans l'écran RÉELLEMENT affiché — le nœud trouvé n'existait pas dans ce graphe-là, donc rien ne se déclenchait, silencieusement. Même limitation pour les animations, dont la timeline ne lisait que les clips propres à l'écran affiché. Logique (templates/play.html) : - findTriggerNode() renvoie désormais { node, screenId } plutôt que juste le nœud, pour transmettre l'écran D'ORIGINE du déclencheur (qui peut être un écran-modèle). - runFlowFrom(nodeId, flowScreenId) accepte un 2e paramètre optionnel (par défaut l'écran affiché, comportement inchangé pour tout le reste) pour exécuter le graphe dans le BON écran. - bindClicks()/bindHoverTriggers() passent maintenant cet écran d'origine à runFlowFrom(). runScreenShowTriggers() (déclencheur "À l'affichage de l'écran") reste volontairement inchangé — hors scope, ambiguïté sur plusieurs exemplaires d'un même modèle sur un écran. Animations (screens/payload/full_game_payload.py, templates/play.html) : - Le payload expose désormais element_types (element_type_id -> id de son écran-modèle), via screens.list_element_types() déjà existant. - collectAnimationClips(screenId) rassemble récursivement les clips de l'écran affiché ET de tout écran-modèle utilisé par un de ses éléments (garde anti-boucle, dédoublonnage par écran). - applyAnimationClip() cible désormais TOUS les exemplaires d'un id d'élément (querySelectorAll, plus querySelector) : un enfant de modèle garde le même id à chaque exemplaire, y compris pour chaque ligne d'un Répéteur utilisant ce modèle comme gabarit de ligne. Limite connue, non corrigée ici (pas la demande) : une action "Modifier un élément" ciblant un enfant de modèle reste, elle, scopée au premier exemplaire trouvé dans le DOM (document.querySelector singulier dans runActionNode/applyElementProperty) — sans impact pour un modèle posé une seule fois par écran, comme dans le cas d'usage actuel. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>Ces onglets ("Logique de la scène", "Timeline d'animation") étaient masqués sur l'écran-modèle d'un élément de jeu réutilisable, avec un commentaire expliquant pourquoi : à l'époque, ses enfants étaient COPIÉS en base avec un NOUVEL id à chaque exemplaire posé (instantiate_template_tree) — une logique/animation posée dans le modèle référencerait donc des ids qui n'existent plus une fois l'élément utilisé ailleurs. Ce mécanisme a depuis été retiré (voir le commentaire dans list_elements.py) : le contenu d'un élément de jeu réutilisable est désormais TOUJOURS rechargé EN DIRECT depuis son écran-modèle à chaque affichage, avec les MÊMES ids à chaque exemplaire. Combiné au commit précédent (findTriggerNode/runFlowFrom/collectAnimationClips côté play.html, qui exécutent maintenant correctement un déclencheur/une animation posé dans un modèle, où qu'il soit utilisé), la restriction de cette page n'avait donc plus lieu d'être — elle bloquait justement la fonctionnalité que le commit précédent venait de rendre possible. Les données nécessaires (flow_nodes/flow_edges/elements du modèle, etc.) étaient déjà calculées sans condition par la route (routes/screens/screen_edit.py) ; seul le template masquait les deux onglets et leur contenu derrière {% if not screen.is_template %}. switchBuilderTab() détecte déjà la présence des panneaux via HAS_FLOW_PANEL/HAS_ANIM_PANEL (document.getElementById), donc aucun changement JS n'était nécessaire. Vérifié en rendant réellement /game/test/screens/3/edit (l'écran-modèle "mail content") via le client de test Flask : les deux onglets sont maintenant bien présents, et l'écran normal (id=1) n'est pas affecté. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>Trois demandes distinctes de l'utilisateur, regroupées car elles touchent toutes à la navigation d'un jeu : 1. Fil d'Ariane retiré (devenu redondant avec la barre de navigation du jeu ajoutée au commit précédent) : bloc breadcrumb_wrap retiré de base.html, et son override ({% block breadcrumb %}) retiré des 9 templates qui le définissaient encore. .breadcrumbBar (CSS) retiré, y compris des règles flex:0 0 auto de body.objectEditBody/builderBody. 2. Liens de .gameNavBar centrés (justify-content:center). 3. "Jouer" déplacé en dernier lien (c'est une action à part — ouvre l'aperçu jouable dans un nouvel onglet — pas un éditeur de plus comme les 4 autres). 4. game_dashboard.html devient un vrai tableau de bord : une grille de cartes (Écrans/Objets/Éléments de jeu/Variables), chacune listant les entrées existantes avec un accès direct (clic = éditeur concerné) et un lien "Gérer" vers la page dédiée pour créer/réorganiser. Remplace l'ancien panneau "Créer" (redondant avec la barre de navigation persistante) et la simple table "Objets définis". routes/games/ game_dashboard.py alimente maintenant aussi screen_list, element_types (+ usage) et variables, en réutilisant list_screens/ list_element_types/element_type_usage_count/list_global_variables déjà utilisés ailleurs. Vérifié en rendant toutes les pages concernées via le client de test Flask : barre de nav présente partout où un `game` est dans le contexte (absente sur l'accueil), fil d'Ariane absent partout, ordre des liens avec "Jouer" en dernier. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>Le précédent dashboard (grille de cartes compactes) ne correspondait pas à ce que l'utilisateur voulait : une seule fenêtre avec de vrais tableaux de données (denses, colonnes nettes), un bouton "Créer" par catégorie dans l'en-tête, et une navigation horizontale pour passer d'une catégorie à l'autre. Réutilise telles quelles .builderTabs/.builderTabBtn/.builderTabPanel (déjà utilisées pour "Écran / Logique / Timeline" dans l'éditeur d'écran) plutôt que d'inventer un 2e système d'onglets — même sensation partout dans l'outil. Un onglet par catégorie (Écrans/Objets/Éléments de jeu/Variables), chacun avec : - un bouton "+ Créer" dans l'en-tête qui révèle une barre de création compacte (repliée par défaut) — sauf pour les Objets, dont la création (plusieurs champs typés) reste sur sa propre page dédiée, trop complexe pour tenir dans une barre ; - le VRAI tableau de gestion de cette catégorie (colonnes, actions), repris tel quel de screens_list.html/element_types.html/ game_variables.html plutôt que réinventé en version appauvrie. La page défile désormais normalement (retrait de body.objectEditBody/ content-objectEdit, pensés pour une hauteur figée avec défilement interne) — une liste peut être longue, pas besoin d'un défilement séparé par panneau ici. routes/games/game_dashboard.py fournit en plus variable_types (db.GLOBAL_VARIABLE_TYPES) pour la barre de création de variable. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>Deux nouveaux types de variable globale (db/constants.py) : "objet" et "tableau" — valeur stockée en JSON (colonne TEXT existante), avec validation à la création/modification (db/global_vars/ coerce_structured_value.py) : un JSON invalide retombe sur un défaut sûr ("{}"/"[]") plutôt que de corrompre silencieusement la variable pour toutes ses lectures suivantes. apply_variable_action.py n'a besoin d'aucun changement — "definir_texte" écrit déjà n'importe quelle chaîne telle quelle. Nouvelle résolution de chemin, partagée (screens/rendering/ filter_repeater_rows.py::_resolve_variable_path) : navigue dans la valeur JSON d'une variable selon un chemin ".champ"/"[index]" chaînable (ex. ".arme.degats", "[0].valeur") — ne lève jamais, renvoie None si le JSON est invalide ou qu'un segment du chemin ne correspond à rien. Branchée à deux endroits, qui lisaient déjà une variable globale : - La valeur de comparaison {{$nom_variable}} (filtres de Répéteur ET Condition de visibilité, qui partagent le même _resolve_filter_value()) accepte maintenant un chemin optionnel : {{$perso.nom}}, {{$scores[0]}}. Le sélecteur "Variable globale" du panneau de propriétés (screen_edit.html, .filterValueVariable) gagne un champ "Chemin optionnel" à côté du choix de variable — même regex étendue côté JS (_VAR_REF_RE) que côté Python (_VAR_REF_PATTERN), pour que la valeur round-trip correctement à la réouverture du panneau. - La variable VÉRIFIÉE par une Condition de visibilité en mode "variable" (choisie via un <select>, pas la syntaxe {{$...}}) gagne son propre nouveau contrôle "Chemin dans la variable" (visibility_condition_ controls.py) — nécessaire pour comparer un champ d'un Objet ou un élément d'un Tableau, pas seulement la variable entière. game_dashboard.html (onglet Variables) : la valeur par défaut de la barre de création devient un <textarea> (fonctionne aussi bien pour un JSON multi-ligne qu'un scalaire court), et la cellule "Valeur" du tableau des variables existantes devient un <textarea> quand le type est objet/ tableau. 4 nouveaux tests (tests/test_variable_object_array.py) : validation JSON à la création, filtre de Répéteur avec chemin chaîné, condition de visibilité avec accès par index de tableau, chemin invalide/absent sans plantage. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>