Les logs montre un chargement de vue et de script/hooks donc nous n’avons pas connaissance.
Regarde les appels Ajax directement pour voir ce qui déclenche le chargement des objets.
preload = avant affichage / avec les données back chargées
display = pour surcharger l’affichage lui même
onload = une fois affiché
Si le formulaire contient d’autres objets, il y aura d’autres hooks sur ces objets qui pourront s’insérer entre les promesses (avant le onload suite à Promise.all finale).
Si la contrainte parle de l’objet lié il faut nécessairement le charger pour tester/changer son comportement en front ?
Si le panel s’affiche dynamiquement, il faut servir l’objet au front et la UI fera juste des show/hide du panel. Je ne pense pas qu’une contrainte fonctionne en lazy loading sur ce point.
Alors après analyse, il y a 1s de perdu entre onloadList associé au RedoLog de notre objet et fom.onload de notre objet. il n’y rien qui se passe dans hook(method, params) du Simplicite.UI.BusinessObject, j’ai du mal à voir ce qui se passe, pour vous donner plus d’information, ou trouver une solution.
Concernant les panels , ce qui a été reproduit en Demo, un objet avec des onglets, tu mets onglets en non visible, tu crée une contrainte avec un inpact sur la visibilité d’un champ, alors les onglets sont bien chargé mais hidden, donc onLoad intervient après chargement des listes et de leurs données associées.
Entre une V5 et une V6, le onload fait suite à une promesse finale pour pouvoir agir sur la page complète = l’objet, les listes liées, load des images asynchrones, les “count” des onglets masqués, contraintes, etc. Avant elle s’exécutait avant la fin du chargement global de la page (juste affichage des fields/areas de l’objet ce qui posait pb si on voulait faire du code sur le reste).
As tu activé le “UI monitoring” front (raccourci habilité) ? ça donne les temps ajax / UI par service, la mémoire utilisée… clique sur une ligne ou sur l’icone jauge pour le détail.
Et que dit l’onglet network du navigateur ?
Tu pourras surement voir si c’est un temps de chargement back ou front.
Oui je pense qu’il y a un axe d’amélioration des perfs sur ce point pour ne charger la liste liée que si la contrainte est bien “visible” / lazy loading. Je vais regarder.
Peux tu me donner la définition exacte de ta contrainte ?
On reproduit bien le chargement avec une contrainte “simple” qui en fonction de la valeur d’un champ rend visible ou non une liste fille (Link) de l’objet parent.
On voit également que les metadata de l’objet lié sont appelées 2 fois, c’est redondant :
displayReferenceList qui appelle displayList avec un parent, chacun recharge les MD via getNavObject
cela fait suite à une évolution qui avait été demandée pour recharger les MD en front dès qu’il y avait un parent = pour appliquer des règles back (type isCreateEnable) dépendantes des data du parent
On va améliorer le comportement :
en ne chargeant le panel contraint que s’il est déjà visible à l’ouverture du formulaire
sinon en lazy-loading lorsque la contrainte front devient visible=true
et en ne cherchant les metadata de l’objet lié qu’une seule fois
On va le faire en V7 dans un premier temps car c’est assez impactant, et on backportera en 6.3 quand on sera rassuré sur la non-regression de l’évolution.
En attendant :
il est toujours possible de retirer la contrainte qui pose des pb de perf
de mettre le link masqué par défaut, il sera non présent dans le DOM
de coder/binder au onload du formulaire des change sur les éléments contraints
pour afficher dynamiquement le panel via displayReferenceList
