Esiste un modo migliore per utilizzare l'ordinamento e il filtro con ILazyTreeContentProvider

Question

Apparentemente se l'uso di ordinamento e filtro ILazyTree(TreePath)ContentProvider non è supportato da TreeViewers. Quindi impostare ViewerFilters o Sorters/Comparators sul TreeView non servirà a nulla. Forse questo è legato al non conoscere tutti gli elementi, compresi quelli non visibili al momento.

A sostegno di questa affermazione qui è javadoc estratto da org.eclipse.jface.viewers.TreeViewer classe:

Se il fornitore di contenuti è un ILazyTreeContentProvider o un ILazyTreePathContentProvider, l'Albero di fondo deve essere creato utilizzando il {@link SWT # VIRTUAL}, il visualizzatore ad albero non supporta l'ordinamento o il filtro e la ricerca hash deve essere abilitata chiamando {@link #setUseHashlookup (booleano)}.

L'unica soluzione che vedo in questo momento è quello di ottenere i bambini per ogni nodo già ordinato. Se hai bisogno di un ordinamento dinamico, cioè di poter commutare l'ordinamento in ordine decrescente o asc durante il tempo di esecuzione, allora devi trovare la tua soluzione per questo, monitorando un flag booleano di sorta durante il riempimento e l'aggiornamento dei bambini, ad esempio.

Siete a conoscenza di soluzioni migliori, forse più API jface che coinvolgono?

Answer 1

Infatti, l'ordinamento non è possibile per un VIRTUAL-TreeViewer se si utilizza un IStructuredContentProvider o un pigro, come indicato nella this thread:

Si dovrà fare il te stesso di ordinamento (nel modello).
L'ipotesi sottostante è che gli elementi potrebbero non essere nemmeno in memoria.

Le cose possono change in e4 (da questo messaggio nel giugno 2009):

IMHO la JFace tabella virtuale e l'attuazione albero non è buono come il none virtuale uno - beh io stare lontano da esso e usalo in nessuno dei miei progetti.

[...] non ha senso avere tavoli virtuali perché dal punto di vista dell'interfaccia utente non ha senso mostrare un utente di 10.000 di elementi e ancora più importante perché il modello rimane residente nella memoria mostrando grande le tabelle con JFace potrebbero consumare tutto il tuo heapspace
(Speriamo di trovare un set ridisegnato di Viewer in E4 che risolva tali problemi).
Vedere this project e bug 260451.
(bug più genral: 167436 e 262160)

questo momento:

stiamo creando un riferimento forte nel visualizzatore dopo il tavolo richiesto.

IMHO sua molto meglio dare all'utente: - paging - possibilità di filtro intelligenti

invece di mostrare milioni di risultati e quindi ad esempio in caso di CDO (Connected Data Objects) il filtraggio avviene sul server usando la loro nuova API di query.