TreeViewer для GridTreeViewer: мост между существующими ITreeContentProviders и «ленивым» ObservableListTreeContentProvider

TL; DR

Основываясь на статье Томаса Шиндла 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 и его подход совершенно иные (иерархия идет от дочернего к родительскому, а не наоборот), а документация, связанная с деревьями , все еще пустой.

10
задан Sk8erPeter 22 March 2017 в 01:32
поделиться