Bonjour, nous avons besoin de pouvoir afficher une liste d’objet de manière regroupée.
Quelles sont les différences entre les concepts “liste en arbre” et “group by” ?
Nous avions déjà mis en œuvre l’affichage “liste en arbre” en version 3.2 legacy mais le paramétrage réalisé à l’époque (2017) semble sans effet sur la V4 responsive.
L’un remplace-t-il l’autre?
Quels sont les cas d’usage standards?
Actuellement voilà un résumé des fonctionnalités qui parlent d’arbre d’objet :
Group by
Permet de grouper sur 1 seul niveau plusieurs champs d’un objet, via un ordre spécifié sur l’attribut d’objet
Typiquement pour lister des objets par type, par date, ou les 2 concaténés
La pagination générale se fait sur les groupes d’attributs trouvés, puis une pagination secondaire se fait par groupe (bouton plus de lignes dans chaque groupe)
Donc il faut compter en terme de perf : 1 search pour les groupes + N search par page de groupe à chaque affichage de la liste
Ca s’applique à toutes les listes / listes principales via menu et aux listes liées en panel
On peut autoriser l’utilisateur à changer le groupement via le popup de recherche
Il y a bouton toggle en bas de liste pour passer en liste normale ou groupée
Liste en arbre
Ca reste une table avec des données cohérentes donc ne s’applique que sur une relation réflexive d’un objet donné vers lui-même
Typiquement pour voir une organisation et ses sous-organisations
On peut préciser la profondeur de recherche au niveau du Link/Relation d’objet
La table indente sur la première colonne les données sous la ligne parente
Niveau perf : gourmand car search récursif jusqu’à la profondeur désirée par branche (ensuite c’est du lazy-loading par action utilisateur pour ouvrir les niveaux inférieurs)
Ne s’affiche que sur les listes filles/panel car il faut obligatoirement partir d’un objet parent/racine.
Treeview
Permet de définir un arbre entre différents objets métier différents en suivant un chemin de foreing-keys : lien direct père/fils, ou via N,N, ou via lien un virtuel pour “sauter” des objets ou faire des jointures particulières (pas sur la clé, par date…)
Affichage en arbre des clés fonctionnelles uniquement (ce n’est pas une table), on peut ajouter des actions ou des styles/décorations
Par exemple : liste de pays / organisation reflexive / personnes / leurs dossiers
Les réflexives sont également parcourues, mais il est parfois conseillé de créer des objets dédiés à un niveau donné : les objets sans parent d’abord puis leurs enfants, sinon tous les objets se retrouvent sur l’objet supérieur (par exemple toutes les orga sous le pays n’est pas souhaitable, on veut plutôt liste de pays / organisation mère / organisation filles / personnes / leurs dossiers)
Performances liées au parcours récursif : coûteux plus il y a de niveaux et de densité des branches (les listes filles sont paginées ou non)
Un treeview peut s’afficher dans le menu, ou dans un écran splitté en 2, ou dans un objet externe d’un formulaire où l’objet est la racine
On peut utiliser le treeeview à chaque niveau si on veut partir d’une organisation par exemple
et il est utilisable par API JSON get/save pour récupérer l’arbre et le mettre à jour sans UI
Les autres champs V3/legacy sont deprecated dans la UI responsive V4+.
Bonjour François, merci beaucoup pour ces explications.
Nous sommes clairement sur l’option 2 (liste en arbre) avec la restitution de zone fonctionnelles décomposées sur N niveaux.
Pour l’instant, seule l’option “liste en arbre” est positionnée à “oui”. Dans cette configuration, j’ai beau consulter les zones fonctionnelles unitairement, je n’ai jamais le [+] attendu dans les listes (filles ou panel) (aucune différence entre les niveaux consultés). Qu’ai-je oublié ?
Merci beaucoup pour ton support.
Alors, c’est assez variable…
Si je pars d’une feuille de l’arbre et que je remonte vers la racine, les sous-arbres déjà ouverts (ou plus précisément, laissés ouverts durant mon parcours) restent ouverts mais les autres branches ne sont ouvertes que le le premier niveau (N=1 relatif à la position courante dans l’arbre).
Par contre, la liste fille affiché est toujours ouverte sur le premier niveau.
Avec une profondeur de -1, tous les niveaux sont en effet ouverts à l’ouverture du formulaire parent.
Est-il possible de considérer des effets différents pour null et 0 ?
0 = arbre actif avec [+] visible mais tout fermé par défaut)
Oui les noeuds ouverts restent en mémoire pour les laisser ouverts quand on revient dessus.
On pourrait effectivement prévoir 2 évolutions :
pouvoir faire un “reset” des noeuds déjà ouverts ou forcer certains noeuds à s’ouvrir. Cette variable est actuellement privée en front, elle indique pour chaque objet métier la liste des row_id ouverts, il faudrait la revoir pour spécifier par object ET par parentId => la liste des ids ouverts.
gérer le “0” comme actif mais non ouvert, et null comme inactif, je pensais utiliser le “1” mais ça implique de décaler tous les paramétrages de 1 sur les projets existants, on va éviter.
en 5.2
La valeur “0” ou “null” est bien gérée pour signifier si la liste liée :
0 = s’affiche en arbre mais replié par défaut
null = ou ne s’affiche pas en arbre du tout
Et au prochain build :
La liste des noeuds ouverts ou fermés par l’utilisateur sur la UI en cours de navigation, sera accessible via l’objet obj._treeOpened qui contient les row_id des noeuds ouverts par instance panel. On peut donc éventuellement ajouter ou retirer des row_id à ouvrir ou fermer.
Par exemple, en forçant ce pointeur à vide au niveau du hook front list.preload et la profondeur du lien à “0”, la liste liée sera toujours repliée à l’ouverture du formulaire parent.
