TL;DR
Sur la base de Thomas Schindl L'article JFace-Viewer et Eclipse Databinding avec > 10.000 objets (ce qui suggère une très bonne idée), j'aimerais convertir un fichier régulier TreeViewer + multiple ITreeContentProvider à la mise en œuvre de La nébuleuse GridTreeViewer qui utilise ObservableListTreeContentProvider , a VisibleRangeChangedListener y Liaison de données Eclipse a le rendre "paresseux" (lazier) et charger les données à la demande .
Comment dois-je réécrire mon texte régulier existant ITreeContentProvider d'utiliser les mêmes hiérarchies avec un nom d'utilisateur et un mot de passe. ObservableListTreeContentProvider ? Puis-je peut-être faire un "pont" entre l'ancienne et la nouvelle solution ? En utilisant DelegatingListProperty en quelque sorte comme este ? D'autres idées ?
J'ai trouvé quelques exemples trop simples, mais je ne comprends pas vraiment le concept d'utilisation de la liaison de données dans un format d'arbre hiérarchique aussi complexe.
Exemples d'arbres et de fournisseurs de contenu :
Fournisseur de contenu 1. :
|- A1
|-- B1
|-- MyMessage1
|- A2
|-- B2
|-- MyMessage2Fournisseur de contenu 2. :
|- C1
|-- D1
|-- MyMessage1
|- C2
|-- D2
|-- MyMessage2Explication plus longue
J'ai une vue où j'affiche une grande quantité d'objets dans un système hiérarchique arbre en utilisant un format personnalisé TreeViewer avec le classique ITreeContentProvider y LabelProvider + ITableLabelProvider mises en œuvre. Il existe également un menu dans lequel l'utilisateur peut choisir le format dans lequel il souhaite voir cette hiérarchie s'afficher. Lorsque l'utilisateur choisit un autre format d'affichage, la seule chose qui se passe est qu'une autre ITreeContentProvider est définie dans le visualiseur et je rafraîchis le visualiseur de manière programmatique.
Cela fonctionne, mais en raison de l'énorme nombre d'éléments (dans certains cas, 100-200k lignes, ne demandez pas les raisons, il faut juste que cela fonctionne), l'affichage des éléments peut être lent l'interface utilisateur se fige parfois, car il y a beaucoup de listeners sur les TreeItems, le rafraîchissement de la vue prend beaucoup de temps, etc...
Donc j'aimerais utiliser une sorte de solution de facilité tout en ayant les éléments du modèle déjà chargés en mémoire.
J'ai déjà essayé SWT.VIRTUAL y ILazyTreeContentProvider mais ses performances sont mauvaises (même en utilisant viewer.setUseHashlookup(true) ) et posait des problèmes (lors du défilement, le chargement des éléments de l'arbre prenait beaucoup de temps, et les éléments de l'arbre n'étaient pas toujours visibles). bogues (problèmes de tri, de filtrage, etc.).
Je lis maintenant l'article du blog de Thomas Schindl : JFace-Viewer et Eclipse Databinding avec > 10.000 objets . J'aimerais essayer en utilisant Grille de la nébuleuse Eclipse 's GridTreeViewer et + ObservableListTreeContentProvider (qui est aussi un ITreeContentProvider ) et une VisibleRangeChangedListener et un fournisseur d'étiquettes "paresseux" (comme dans l'article). Puis-je en quelque sorte utiliser mon ITreeContentProvider et de construire un "pont" entre celle-ci et une nouvelle ObservableListTreeContentProvider ?
J'ai vérifié Nebula NatTable mais j'ai trouvé TRÈS difficile de faire migrer les fournisseurs de contenu existants vers cette nouvelle solution, car son API et son approche sont totalement différentes (la hiérarchie va de l'enfant au parent, et non l'inverse), et la documentation relative à l Arbres est toujours vide.
