Refonte du Scenario en arbre de decision (modale dediee, plus de vrai/faux
Build and deploy / test-python (push) Failing after 1m15s
Build and deploy / test-js (push) Successful in 54s
Build and deploy / lint-python (push) Failing after 1m12s
Build and deploy / lint-js (push) Failing after 1m8s
Build and deploy / build-and-push (push) Skipped
Build and deploy / deploy (push) Skipped
Build and deploy / sonarqube (push) Failing after 1m4s

Retour utilisateur : "une consequence peut mener a d'autres choix et
ainsi de suite, il n'y a pas de notion vrai/faux, il faut une modale
avec la possibilite de construire un veritable arbre de choix
consequence". Remplace le modele plat (situation + 2-4 choix + un seul
bon choix + une consequence terminale) par un vrai graphe de nœuds :
{"title", "nodes": [{"id", "text", "choices": [{"text", "target_id"}]}]}
- nodes[0] est la situation initiale, chaque choix peut pointer vers
n'importe quel autre nœud (branchement, convergence, fins multiples),
un nœud sans choix est une fin de branche valide. Aucune notion de
bonne/mauvaise reponse.

L'arbre se construit desormais dans une modale dediee (trop de
structure pour la colonne etroite du panneau Proprietes) : liste de
nœuds, chaque choix avec un menu deroulant "mene a" listant les autres
nœuds ou "fin de branche". La modale est un composant generique
(.docModal*) independant de tout framework externe.

sanitize_scenario_config degrade silencieusement tout target_id
orphelin (nœud supprime) vers None plutot que de faire echouer le
scenario entier. Le lecteur cote client navigue le graphe nœud par
nœud, le texte du nœud visite remplace le precedent (toujours pas un
Quiz), jusqu'a une fin de branche puis passage au scenario suivant.

Verifie via simulation DOM reelle (jsdom) : navigation ramifiee
(branchement, convergence, fin via nœud vide ET via choix sans cible),
plusieurs arbres a la suite, et l'editeur modal complet (ouverture,
ajout/suppression de nœud avec reparation des references pendantes,
changement de cible, fermeture bouton/fond/Echap).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
william
2026-09-20 17:29:24 +02:00
co-authored by Claude Sonnet 5
parent c04a81cfec
commit a529857379
9 changed files with 679 additions and 296 deletions
@@ -461,23 +461,27 @@ def _render_mots(el: dict[str, Any], _children_by_parent: dict[int | None, list[
def _render_scenario_player(config: dict[str, Any]) -> str:
"""Mise en situation RÉELLEMENT interactive — affichée uniquement en
Mode Aperçu, même principe que les autres mini-jeux : aucun
aller-retour serveur, tout le déroulé (lecture de la situation, choix,
conséquence révélée, scénario suivant) est géré par
static/document/js/document-editor.js à partir du JSON embarqué. Les
scénarios gardent l'ORDRE d'écriture du créateur (contrairement à
aller-retour serveur, tout le déroulé (navigation dans l'arbre de
décision, scénario suivant) est géré par static/document/js/
document-editor.js à partir du JSON embarqué (voir scenario_config.py
pour la forme exacte d'un scénario : {"title", "nodes"}, nodes[0]
étant la situation initiale). Les scénarios (plusieurs arbres
indépendants) gardent l'ORDRE d'écriture du créateur (contrairement à
l'Association/Memory/Mots mêlés, jamais mélangés) : ce sont des mises
en situation séquentielles, pas des éléments à faire correspondre ou
retrouver — un mélange n'aurait ici aucun sens pédagogique. Un seul
bloc de texte (.docScenarioSituation) sert successivement à afficher
la situation PUIS, une fois un choix fait, la conséquence à sa place
(les boutons de choix disparaissent aussi) — volontairement PAS le
comportement du Quiz, où la question reste affichée à côté d'un
encart de feedback séparé (retour utilisateur du 20/09/2026 : "ce
n'est pas un quiz, la conséquence s'affiche à la place de la
situation précédente"). Réutilise les classes visuelles du Quiz
(.docQuizOptions/.docQuizFeedback/.docQuizNextBar/
.docQuizQuestionText) plutôt que de dupliquer ces règles, même esprit
que .docAssocCard/.docMinigameRestartBar."""
le texte de chaque nœud visité : une fois un choix fait, le texte du
nœud suivant REMPLACE le précédent (les boutons de choix disparaissent
avec lui) — volontairement PAS le comportement du Quiz, où la
question resterait affichée à côté d'un encart de feedback séparé.
Aucune notion de bonne/mauvaise réponse ici (retour utilisateur du
20/09/2026 : "il n'y a pas de notion vrai/faux, l'utilisateur observe
les conséquences") — un nœud sans choix est simplement une fin de
branche. Réutilise les classes visuelles du Quiz
(.docQuizOptions/.docQuizNextBar/.docQuizQuestionText) plutôt que de
dupliquer ces règles, même esprit que .docAssocCard/
.docMinigameRestartBar."""
config_json = html_lib.escape(json.dumps({"scenarios": config["scenarios"]}), quote=True)
return (
f'<div class="docScenarioPlayer" data-scenario-config="{config_json}">'
+27 -17
View File
@@ -102,25 +102,35 @@ regroupement à chaque appel.
scénarios) — sanitizée (`sanitize_scenario_config`) avant lecture. Si
au moins un scénario existe, s'y ajoute (fonction privée
`_render_scenario_player`) la mise en situation RÉELLE et interactive :
l'apprenant lit la situation, choisit une option, puis la conséquence
de SON choix REMPLACE l'affichage de la situation (les boutons de
choix disparaissent avec elle) avant de passer au scénario suivant —
volontairement PAS le comportement du Quiz, où la question resterait
affichée à côté d'un encart de feedback séparé (retour utilisateur du
20/09/2026 : "ce n'est pas un quiz, la conséquence s'affiche à la
place de la situation précédente"). Les scénarios gardent l'ORDRE
d'écriture du créateur (jamais mélangés, contrairement à
Association/Memory/Mots mêlés — ce sont des mises en situation
un scénario est un ARBRE DE DÉCISION (voir `scenario_config.py` pour la
forme exacte — `nodes[0]` = situation initiale, chaque choix pointe
vers un autre nœud via `target_id`, un nœud sans choix est une fin de
branche), pas une simple question à une seule conséquence. Aucune
notion de bonne/mauvaise réponse (retour utilisateur du 20/09/2026 :
"il n'y a pas de notion vrai/faux, l'utilisateur observe les
conséquences") : l'apprenant choisit une option, le texte du nœud visé
REMPLACE l'affichage du nœud précédent (les boutons de choix
disparaissent avec lui), et ainsi de suite jusqu'à une fin de branche
— volontairement PAS le comportement du Quiz, où la question resterait
affichée à côté d'un encart de feedback séparé. Une fois une fin de
branche atteinte, passage au scénario (arbre) suivant. Les scénarios
gardent l'ORDRE d'écriture du créateur (jamais mélangés, contrairement
à Association/Memory/Mots mêlés — ce sont des mises en situation
séquentielles, pas des éléments à faire correspondre/retrouver).
Réutilise les classes visuelles du Quiz (`.docQuizOptions`/
`.docQuizFeedback`/`.docQuizNextBar`/`.docQuizQuestionText`) plutôt que
de dupliquer ces règles. Embarqué en
JSON dans un attribut `data-scenario-config`, échappé pour l'HTML —
même principe que les autres mini-jeux, aucun aller-retour serveur
pendant qu'on joue. Comme l'Association/Memory/Mots mêlés (mais
contrairement au Quiz), le dernier scénario reste affiché une fois
répondu : seul le bouton "Recommencer" (`.docMinigameRestartBar`)
apparaît.
`.docQuizNextBar`/`.docQuizQuestionText`) plutôt que de dupliquer ces
règles. L'arbre complet (tous les nœuds/choix de tous les scénarios)
est embarqué en JSON dans un attribut `data-scenario-config`, échappé
pour l'HTML — même principe que les autres mini-jeux, aucun
aller-retour serveur pendant qu'on joue : toute la navigation dans
l'arbre se fait côté client. Comme l'Association/Memory/Mots mêlés
(mais contrairement au Quiz), le dernier scénario reste affiché une
fois une fin de branche atteinte : seul le bouton "Recommencer"
(`.docMinigameRestartBar`) apparaît. L'arbre lui-même se construit
dans une MODALE dédiée depuis le panneau Propriétés (voir
`forgeDocOpenScenarioTreeModal`, static/document/js/document-editor.js)
— trop de structure (nœuds + choix + destinations) pour la colonne
étroite du panneau Propriétés, contrairement aux autres mini-jeux.
- **Autres mini-jeux** (`zones`) : carte placeholder portant le libellé
du type (voir `document_engine/labels/element_kind_labels.py`) —
emplacement réservé, formulaire de contenu dédié hors périmètre de