unclean SPARC

app/assets/json/tests/model_bug.txt

@@ -0,0 +1,80 @@
+ ***********************************************
+ * Raiders of the lost-arcmodel (archaïc model)* 
+ ***********************************************
+
+===> Le comportement zarb: 
+On édite une propal, on refocus le dashboard, on clique sur view de la même propal (probablement idem si edit) :
+La propal se re-focus, mais les dernières données encodées n'y sont pas. 
+Biensur, réessayé en veillant bien à attendre le temps de l'auto-save, 
+vérifié en voyant passer le PUT en console-network mais le blème est bien côté FE.
+
+
+
+===> L'enquête:
+- Suivit le reloading des données en les dumpant partout, depuis le modèle (reload OK, données fraiches, donc effectivement c'est pas le BE) 
+jusque dans la vue ou -surprise- elles sont périmées. 
+- Pourtant séquence temporelle correcte, on a bien le model.getPropa avant le view.fill
+- Finalement soupçon sur l'instantiation des modèles => mise (temoraire) d'un UUID random comme propriété du modèle dans son constructeur. 
+  Du coup on peux tracer les changements d'instance.
+
+
+===> Le diagnostique:
+L'utilisateur sur le dashboard, fait un "Edit" sur la propal (première ouverture de cette propal):
+- Route vers "SubmissionController::proposal"
+- Ctrl instancie le model submissionModel (instance SM1)
+- Ctrl load les datas dans SM1.data
+        THEN il fait un this.loadwindow (SumissionShortForm2023View), passe tous les modeles (dont SM1)
+             son ancêtre "EICcontroller" fait un "createwindow", et un "loadview" : param "data.models" =tous les modeles (dont SM1)
+- "DOMContentLoaded(options)" est lancé dans la view "SubmissionShortForm2023View", SM1 arrive par "options.models", devient "this.submission"
+- La view-propal fait des "fill()" pour tous les tabs, prend ses datas dans "this.submission" donc dans SM1.data  ===> all good
+
+- Ensuite, le user refocus la fenetre dashboard et fait un "view" sur la même propal. (probablement un "edit" aurais le même comportement)
+- Route vers "SubmissionController::proposal"
+- Ctrl instancie le model submissionModel (instance SM2)    ====> aie !
+- Ctrl load les datas fraiches dans SM2.data
+        THEN il fait un loadwindow (SumissionShortForm2023View), passe tous les modeles (dont SM2)
+        son ancetre "EICcontroller" conmait cette fenetre, et donc fait un "this.focus" (pas un create) param "data" = tous les modeles (dont SM2)
+- "DOMContentFocused(data)" est lancé dans la view "SubmissionShortForm2023View", qui recoit SM2 via options.models 
+- MAIS "DOMContentFocused" se fout pas mal de options.models  ====> ouille !
+   This.submission reste donc l'instance SM1 pas fraiche ====> et bardaf, c'est l'embardée !
+   
+
+- Biensur, Si on continue les allez-retour, il y a chaque fois une nouvelle instance de modèle, 
+  mais les tabs continuent d'utiliser la toute première instance ===> aie-ouille-bardaf !
+
+
+===> Le fix:
+
+1. Patché d'abord en réassignant les modèles dans DOMContentFocused de "SubmissionShortForm2023View". (fastoche)
+
+!!! Oui mais, dans le cas des Tabs ca ne suffit pas, car les tabs ne sont pas réinstanciés nonplus.
+De plus, leur "DOMContentFocused" n'est jamais appelé.
+
+2. Ajouté un appel à "DOMContentFocused" pour tous les chunks.view dans "SubmissionShortForm2023View::DOMContentFocused" pour propager le focus aux tabs
+
+3. Ensuite ajouté un "DOMContentFocused" dans la maman des tabs "SubmissionShortFormTabView" qui assigne this.model avec options.models.sumbission (options.models étant maintenant dispo)
+
+Du coup les vues & tabs ont la dernière instance du modèle, créée en réentrant dans le CTRL et donc les données fraiches.
+...Reste a espérer qu'il ne traine plus de refs sur la vielle instance de modèle et qu'elle soit donc proprement garbage-collectée.
+
+
+Attention, du coup sémentiquement : "DOMContentFocused" d'un tab veux dire "la fenêtre à laquelle le tab appartient est refocussée",
+a ne pas confondre évidemment avec le focus du tab lui-même ( = event 'selected' du composant).
+
+
+Makes me wonder : dommage qu'on réinstancie le modèle (en général, même fenêtre (avec mêm url dont params) = mêmes données, 
+le rafraichissement éventuel des données pourrais aussi bien se faire sans changer d'instance de modèle. 
+Mais lorsque EICcontroller teste pour voir si c'est une fenetre connue, il est déjà trop tard :
+le ctrl-fiston a déjà instancié et choppé les datas, d'ailleurs c'est même obligatoirement synchrone avant de lancer la fenetre : via le THEN)
+D'un autre côté, créer une association modèle-window (pour savoir si on l'a déjà plus tôt) n'est clairement pas un bon pattern...
+... A méditer avec un malibu-ananas.
+
+Si on reste sur le patch ci-dessus, faut bien garder ca en tête paske ce pattern => bug potientiel va se retrouver ailleurs !
+
+
+
+===> Side-effect & Fix on the fix : 
+Dans certains cas les focus sont appelés sans options (lorsqu'on clicke sur les badges fenêtre). 
+=> rajouté un test pour ne pas tenter de recopier les modèles si pas d'options. 
+   Pas grave parceque ca correspond au cas ou on refocus la fenêtre sans rerouter, donc avec modèles non-réinstanciés.
+   Mais j'adore pas tout ca... faudrat qu'on en cause, voir si on peut clarifier/simplifier.