Anomalie #16838
fermé[Ecran principal] Temps de chargement de dossiers virtuels
Description
Lorsqu'une activité comporte beaucoup de dossiers virtuels (+10000) le chargement de l'arborescence est très long.
Analyse
Affichage par presenter recordsManagement/welcome/welcomePage
Voir délai pour l'appel au service 'filePlan/filePlan/readTree'
Voir délai de construction côté presenter html
Voir délai de construction du html par le JS
Selon les résultats:
- ne charger en back que le premier niveau et ajouter des routes pour charger le contenu d'un répertoire lorsque l'utilisateur l'ouvre
- charger toutes les niveaux mais seulement construire le html avec le JS lorsque l'utilisateur l'ouvre
Fichiers
Mis à jour par Cyril VAZQUEZ il y a plus de 3 ans
Pb lié à la traduction:
Quand l'instruction de fusion a pour cible non pas un noeud déjà présent mais un fragment, il n'est pas possible de traduire avant fusion.
La traduction a donc été faite après, mais sur la répétition de milliers d'éléments cela pose problème:
<?merge data /chemin/template.html ?>
Comme template est inclus au doc au moment de la fusion, il ne peut être traduit avant fusion.
Solution:
Nouvelle fonctions dans le système de templating pour ajouter des fragments au document sans les inclure dans l'arbre DOM
Modification de la fonction de traduction pour permettre de traduire ces fragments avant fusion
Modification du système de fusion pour utiliser en priorité les fragments déjà présents au lieu de les charger des fichiers à partir de l'URI précisée dans l'instruction de fusion
résultat = lorsque la fusion d'un tableau utilise une cible qui est un fragment, le fragment déjà présent et traduit est utilisé
Mis à jour par Cyril VAZQUEZ il y a plus de 3 ans
Second problème lié à la récursivité lors de la construction de l'arbre.
La lecture en DB renvoie un tableau de dossiers.
Le contrôleur fait appel à laabs::buildTree pour construire l'arbre.
laabs::buildTree fait appel à laabs::buildBranch récursivement
Création d'un buildTree2 qui n'est pas récursif mais utilise un nouveau tableau indexé par id d'objet
Mis à jour par Alexandre GOLDSTEIN il y a plus de 3 ans
Tests réalisés à ce jour avec 10000 dossiers : on a 5 sec de délai sur la branche contenant la correction, le spinner ne s'arrete pas sur la branche develop (les dossiers ne sont jamais affichés)
Tests egalement fait avec 2000 dossiers : on a 2,22 sec de délai d'affichage sur la branche corrective, et 6.02 sec en comparaison sur la branche develop
Mis à jour par Alexandre GOLDSTEIN il y a plus de 3 ans
- Statut changé de A traiter à A livrer
Mis à jour par Emmanuel DILLARD il y a plus de 3 ans
- Projet changé de 252 à Backlog RM
- Version cible changé de 2.7.3 à 2.7
- Tags RM 2.7.3 ajouté
Mis à jour par Emmanuel DILLARD il y a plus de 3 ans
- Statut changé de Livré à R&D - Terminé