Existe-t-il un meilleur moyen d'utiliser le tri et le filtrage avec ILazyTreeContentProvider?

Question

Apparemment, si le tri ILazyTree(TreePath)ContentProvider et le filtrage ne sont pas supportés par TreeViewers. Donc, régler ViewerFilters ou Sorters/Comparators sur votre TreeView ne fera rien. Peut-être est-ce lié au fait de ne pas connaître tous les éléments, y compris ceux qui ne sont pas visibles pour le moment.

À l'appui de cette déclaration est extrait javadoc ici de org.eclipse.jface.viewers.TreeViewer classe:

Si le fournisseur de contenu est un ILazyTreeContentProvider ou un ILazyTreePathContentProvider, l'arbre sous-jacent doit être créé en utilisant la {@link SWT # VIRTUAL} style, l'arborescence ne prendra pas en charge le tri ou le filtrage, et la recherche de hachage doit être activée en appelant {@link #setUseHashlookup (boolean)}.

La seule solution que je vois actuellement est d'obtenir les enfants pour chaque noeud déjà commandé. Si vous avez besoin d'un tri dynamique, c'est-à-dire que vous pouvez changer l'ordre de tri en ordre décroissant ou asc pendant l'exécution, vous devez créer votre propre solution, en surveillant par exemple un drapeau booléen lors du remplissage et de la mise à jour des enfants.

Etes-vous au courant de meilleures solutions, peut-être plus API jface impliquant?

Answer 1

En effet, le tri est impossible pour un VIRTUAL-TreeViewer si vous utilisez un IStructuredContentProvider ou un paresseux, comme il est indiqué dans this thread:

Vous devrez faire vous-même le tri (dans votre modèle).
L'hypothèse sous-jacente est que les éléments pourraient même ne pas être en mémoire.

Les choses peuvent change in e4 (de ce message en Juin 2009):

à mon humble avis le JFace Tableau virtuel et la mise en œuvre Tree est pas aussi bon que le pas virtuel - et je reste loin de lui et Utilisez-le dans aucun de mes projets.

[...] son ​​absurde d'avoir des tables virtuelles car d'un point de vue UI-Design il est insensé de montrer un utilisateur 10.000s d'éléments et encore plus important car le modèle reste résident dans votre mémoire affichant de grandes tables avec JFace pourraient manger tout votre espace
(Nous espérons arriver à un ensemble de visionneuses repensé dans E4 qui corrigent de tels problèmes).
Voir this project et bug 260451.
(plus de bugs genral: 167436 et 262160)

En ce moment:

nous créons une référence forte dans le spectateur après la table l'a demandé.

à mon humble avis est beaucoup mieux pour donner à l'utilisateur: - pagination - possibilités de filtrage intelligentes

au lieu de montrer millions de résultats, puis par exemple dans le cas de CDO (Connected Data Objects) le filtrage se passe sur le serveur en utilisant leur nouvelle API de requête.