开发者

Is there a better way to use sorting and filtering with ILazyTreeContentProvider

开发者 https://www.devze.com 2022-12-13 01:59 出处:网络
Apparently if using ILazyTree(TreePath)ContentProvider sorting and filtering is not supported by TreeViewers. So setting ViewerFilters or Sorters/Comparators to your TreeView won\'t do any good. Perha

Apparently if using ILazyTree(TreePath)ContentProvider sorting and filtering is not supported by TreeViewers. So setting ViewerFilters or Sorters/Comparators to your TreeView won't do any good. Perhaps this is related to not knowing all elements, including those not visible at the moment.

In support to this statement here is javadoc excerpt from org.eclipse.jface.viewers.TreeViewer class:

If the content provider is an ILazyTreeContentProvider or an ILazyTreePathContentProvider, the underlying Tree must be created using the {@link SWT#VIRTUAL} style bit, the tree viewer will not support sorting or filtering, and hash lookup must be enabled by calling {@link #setUseHashlookup(boolean)}.

The only solution I see at the moment is to get the children for each node already ordered. If you need dynamic sorting, i.e., being able to switch sort开发者_如何学JAVAing order in desc or asc order during run time, then you need to come up with your own solution for this, monitoring a boolean flag of sorts when filling and updating children for example.

Are you aware possibly of better solutions, perhaps more jface API involving?


Indeed, sorting is not possible for a VIRTUAL-TreeViewer whether you use a IStructuredContentProvider or a lazy one, as noted in this thread:

You will have to do the sorting yourself (in your model).
The underlying assumption is that the elements might not even be in memory.

Things may change in e4 (from this message in June 2009):

IMHO the JFace Virtual Table and Tree implementation is not as good as the none virtual one - well I stay away from it and use it in none of my projects.

[...] its senseless to have virtual tables because from an UI-Design point of view it is senseless to show an user 10.000s of elements and even more important because the model stays resident in your memory showing big tables with JFace might eat up all your heapspace
(We hope to come up with a redesigned set of Viewers in E4 who fix such problems).
See this project and bug 260451.
(more genral bugs: 167436 and 262160)

Right now:

we are creating a strong reference in the viewer after the table requested it.

IMHO its much better to give the user: - paging - intelligent filtering possibilities

instead of showing million of results and then e.g. in case of CDO (Connected Data Objects) the filtering happens on the server using their new query-API.

0

精彩评论

暂无评论...
验证码 换一张
取 消