***********************************************
 * 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.