Основываясь на статье Томаса Шиндла JFace-Viewer и Eclipse Databinding с> 10.000 объектов (что предлагает очень хорошую идею), Я хотел бы преобразовать обычные TreeViewer
+ множественные ITreeContentProvider
реализации в GridTreeViewer
туманности, в которой используются ObservableListTreeContentProvider
, VisibleRangeChangedListener
и Eclipse Data Binding , в сделать его «ленивым» (lazier) и загружать данные по требованию .
Как мне переписать мои существующие обычные ITreeContentProvider
реализации, чтобы использовать те же иерархии с ObservableListTreeContentProvider
? Могу ли я сделать «мост» между старым и новым решением? Использование DelegatingListProperty
как-то похоже на , это ? Любые другие идеи?
Я нашел несколько слишком простых примеров, но я не совсем понял концепцию использования привязки данных в таком сложном формате иерархического дерева.
Примеры деревьев и поставщиков контента:
Поставщик контента 1.:
|- A1
|-- B1
|-- MyMessage1
|- A2
|-- B2
|-- MyMessage2
Поставщик контента 2.:
|- C1
|-- D1
|-- MyMessage1
|- C2
|-- D2
|-- MyMessage2
У меня есть представление, где я отображаю огромное количество объектов в иерархическом формате дерева , используя пользовательские TreeViewer
с классическими ITreeContentProvider
и LabelProvider
+ ITableLabelProvider
реализации. Существует также меню, в котором пользователь может выбрать, в каком формате он хочет видеть эту иерархию. Когда пользователь выбирает другой формат отображения, единственное, что происходит, это то, что другая реализация ITreeContentProvider
устанавливается для зрителя, и я обновляю зрителя программным путем.
Это работает, но из-за огромного количества элементов (в некоторых случаях 100-200 тыс. Строк, пожалуйста, не спрашивайте причины, это просто должно работать), отображение элементов может быть медленным , Пользовательский интерфейс иногда зависает, потому что в TreeItems очень много слушателей, обновление представления занимает много времени и т. Д.
Так что я бы хотел использовать своего рода ленивое решение , когда элементы модели уже загружены в память.
Я уже пробовал SWT.VIRTUAL
и ILazyTreeContentProvider
, но он работал плохо (даже если использовал viewer.setUseHashlookup(true)
) и был проблематичным (при прокрутке TreeItems загружалось много времени, были ошибки , проблемы с сортировкой, фильтрацией и т. д.).
Теперь я читаю статью в блоге Томаса Шиндла: JFace-Viewer и Eclipse Databinding с> 10.000 объектов . Я хотел бы попробовать это, используя Eclipse Nebula Grid GridTreeViewer
и + ObservableListTreeContentProvider
(что также является реализацией ITreeContentProvider
) и VisibleRangeChangedListener
и «ленивый» провайдер меток (как в статье). Могу ли я каким-то образом использовать мои существующие реализации ITreeContentProvider
и построить «мост» между этим и новым ObservableListTreeContentProvider
?
Кстати, я проверил туманность NatTable , но нашел ОЧЕНЬ трудно перенести существующих поставщиков контента в это новое решение, его API и его подход совершенно иные (иерархия идет от дочернего к родительскому, а не наоборот), а документация, связанная с деревьями , все еще пустой.