Community
Participate
Working Groups
to keep model and viewer in sync when using add/remove one needs some custom code and this can easily lead to inconsitency between what is represented in the view and underlying model. I think it would make sense if we provide some model-modification-events.
Yes - but this already exists in the form of IObservableSet/IObservableList. IObservableList is the new IStructuredContentProvider (if you don't use a sorter on the viewer and would like to control the order of elements). IObservableSet is the new IStructuredContentProvider (if you set a sorter on the viewer). In JFace data binding, we have adapters for turning one of these into an old-style content provider.
well but i think this should also be available for none databinding users. Can we move it from there to JFace?
You don't have to use all of data binding in order to use IObservableSet as a replacement for what used to be the content provider. Just like you don't have to use all of JFace if all you need is a tree viewer. IObservableSet/List/Map/Value don't even depend on JFace or SWT so no, I would not put that into JFace.
The input observable list or set cannot be reliably used for determining what elements are actually present in the viewer, if the viewer has any filters. This could be solved either by adding a listener API to JFace, or by introducing filtered lists / sets into DataBinding.
(In reply to comment #4) > The input observable list or set cannot be reliably used for determining what > elements are actually present in the viewer, if the viewer has any filters. > This could be solved either by adding a listener API to JFace, or by > introducing filtered lists / sets into DataBinding. I am leaning towards introducing filtered lists and sets into the data binding framework.
Hitesh is now responsible for watching bugs in the [Viewers] component area.
