Paramétrage "liste en arbre" vs "group by" sur une relation reflexive (fk parentId)

Tags: #<Tag:0x00007f2f2fa284c8>

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?

Bonjour,

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

1 Like

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.

Il faut mettre une profondeur positive au niveau du Link/Relation d’objet (ou sinon -1 = deep search)
sinon je ne vois pas ce qui pourrait manquer.

C’était bien ça… à présent, ça fonctionne “en toute simplicité” ;)
Merci beaucoup!

Addendum: est-il possible de paramétrer la liste fille pour que l’arbre soit refermé par défaut ?

Si tu mets profondeur = 1 ?

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)
  • null (vide) = arbre inactif

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.

1 Like