Community
Participate
Working Groups
Created attachment 55405 [details] random stuff
More random stuff can be found in bug 167010. ;)
A hard, but interesting nut to crack ;-)
*** Bug 202087 has been marked as a duplicate of this bug. ***
*** Bug 153825 has been marked as a duplicate of this bug. ***
One of the difficulties in live filtering of observable lists / sets is that you would want to update the list when an element changes in a way pertinent to the filtering criteria. For example if we have a filter "age >= 18", then you want to observe the age attribute for each element in the collection and automatically remove or add that element to the filtered collection as appropriate.
There are two possible approaches: 1. Use ObservableTracker to automatically add the required listeners, similar to how e.g. TableUpdater works. 2. Make it explicit, i.e. require that the user specify a list of properties that are being accessed, similar to how ObservableMapLabelProvider works.
Consider these use cases: a) We want to filter an IObservableList based on a search field. In this case the filter criteria is what changes. This could be captured by ObservableTracker. When the filter criteria changes the whole collection should be refiltered. b) We want to filter an IObservableList based on some criteria (e.g. age >= 21) where the elements may change in a way that affects their inclusion in the list (e.g. person.setAge(18)). ObservableTracker could capture but we would only be getting generic change events, so rather than doing selectively updating just the elements that changed, we have to refilter the whole list. To take advantage of targeted updates So we have two types of dependencies: the filtering criteria and the filtered data which is compared with that criteria. When the criteria changes we must do a full refilter. When the data changes we should add / remove just those elements to the filtered list as appropriate. I think what we need is an API where we can express the filter criteria as an array of IObservables, and/or express the filter-relevant element properties. I think that like JFace viewers we should adopt an IFilter approach where a FilteringList can have several filters added to it: class FilteringList { public void addFilter(IFilter) public void removeFilter(IFilter) public void setFilters(IFilter[]) public IFilter[] getFilters() } Having the ability to add / remove / set all filters should satisfy case (a) above. To handle case (b) we can have some API in IFilter to get an IObservableMap[] mapping from unfiltered elements to whatever attributes are relevant to the filter. When any map changes values, the associated key would be refiltered. interface IFilter { boolean select(Object element) IObservableMap[] observeDependencies(IObservableSet elements) } Thoughts?
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=262160#c11 for some relevant discussion to collection filtering.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
