QAbstractTableModel и два представления: нужен совет...

[ритт]

схема "одна общая модель + 1-2 прокси-модели + 2 представления + дополнительные роли

[Cyrax]

1-2 прокси-модели

1 прокси-модель, я так понимаю, - когда общая модель данных M заточена под одно из представлений (например, наследник QAbstractTableModel, работающий с представлением напрямую, не нуждается в прокси P_table) ?
(в данном случае понадобится одна прокси-модель P_tree для работы с представлением V_tree)

Таким образом, пусть модель M будет заточена под табличное представление V_table. Т.е. V_table пусть будет основным представлением, V_tree - дополнительным, нуждающимся в прокси-модели P_tree:
- одна общая модель M,
- одна прокси-модель P_tree для работы общей модели M с представлением V_tree,
- 2 представления V_table и V_tree.
Общая модель M работает с основным представлением V_table напрямую, с дополнительным V_tree - через прокси P_tree. Тогда:
1. При запросе/установке данных представлением V_table общая модель M работает с обычными индексами (индекс таблицы), соответствующими ячейкам таблицы и со стандартными ролями Qt.
2. При запросе/установке данных представлением V_tree прокси-модель P_tree индекс (индекс дерева) оставляет неизменным, а роль изменяет на одну из пользовательских (дополнительных) ролей.

Так ?

[ритт]

неверно, начиная с понимания, что модели заточены под вьюхи

[Tonal]

Я бы сделал так:
Реализовал слой логики, которая ничего о Qt может и не знать.
В этом слое есть твой хитрый контейнер, у которого есть методы для доступа как к таблице (имя атрибута, номер строки) и как к дереву (родитель, итератор по детям)...
Далее в логике представления рисуем модели, которые не имеют своих данных, а лишь обращаются к соответствующим методам доступа логики.

[Cyrax]

неверно, начиная с понимания, что модели заточены под вьюхи

Именно. Тогда как архитектура/концепция "модель-представление" подразумевает абстракцию данных от представления...
xep, касательно моего предыдущего поста - такую реализацию ты имелл вииду или нет ?
Или не думал над конкретикой/деталями ?

Я бы сделал так:
Реализовал слой логики, которая ничего о Qt может и не знать.
В этом слое есть твой хитрый контейнер, у которого есть методы для доступа как к таблице (имя атрибута, номер строки) и как к дереву (родитель, итератор по детям)...
Далее в логике представления рисуем модели, которые не имеют своих данных, а лишь обращаются к соответствующим методам доступа логики.

Все предлагаемые варианты крутятся вокруг одной схемы: "объект с общими данными + 2 представления + 2 промежуточных объекта".
Т.е. имеются следующие варианты:
1. общая модель M + 1 или 2 прокси-модели P_tree и P_table + 2 представления
2. общая модель M + 2 модели M_tree и M_table + 2 представления
3. класс с общими данными + 2 модели M_tree и M_table + 2 представления
Пока предлагаются "голые" варианты. А хотелось бы услышать преимущества и особенности предлагаемых вариантов...
3-й вариант мне пока больше нравится...

[Racheengel]

Под вьюхи заточены прокси-модели, а не модель М. Модель М вообще не должна знать, как должны отображаться данные - она просто их содержит. А вот уже прокси-модели выгребают из М то, что надо показать во вьюхе.

Варианты 1 и 3 в принципе идентичны, если считать модель М этим самым классом с общими данными (он может быть вообще не Qt-моделью). Лично я бы так и делал - класс с данными и две прокси.

[ритт]

нет, не такую...

модель, две прокси-модели, две вьюхи
примера ради: одна прокся оперирует данными роли ДисплэйРоле, другая прокся - данными роли ЭдитРоле. соответственно, каждый индекс будет возвращать на ДисплэйРоле, например, название значения, а на ЭдитРоле - само значение...или наоборот...или же вообще провести свои роли. в таком случае та же таблмодель тебе даст массив не двумерный, а размерностью [столбцов * строк * кол-во уникальных ролей]
плюсы: модели срать с прибором на то, кто её пользует, в частности, её же можно использовать в связке с любыми кутэшными вьюхами; не надо "расширять интерфейс"; перестраивать индексы придётся только при скрытии строк/столбцов (прокси-модели это умеют и без тебя)
в идеале можно обойтись только наследованием модели эМ, а проксям тупо указать роль, с которой забирать дату по сырцо-индексам
из минусов: если в дереве действительно древовидное отображение (больше 1-2 дочерних нод), таблмодель в качестве модели эМ плохо подходит, т.к. будет ассертить на валидные парентИндексы

из перечисленных у тебя выше трёх вариантов второй - вообще непотреб. выбирать надо из первого и третьего - всё зависит от структуры/сложности исходных данных

[Tonal]

2 Cyrax Насколько я понимаю, мой вариант это №3 по твоей классификации.
Мы успешно его применяем.
Главное достоинство подхода - разделение обязанностей.
Если по пунктам, то примерно так:
1) Класс логики содержит только логику, без ненужных ему привязок к GUI да и вообще к Qt.
Соответственно тестировать, да и вообще использовать его можно совершенно отдельно от остального приложения (у нас, например, такие классы используются в разных конверторах)
2) Классы Qt моделей довольно просты и содержат только логику конвертации и стандартное представление дерева или таблицы соответственно, ошибок в них меньше, а писать проще.

[Cyrax]

Блин, ну чё за язык: "срать с прибором", "забирать дату по сырцо-индексам".
Что такое "срать" ?  Что такое "прибор" ?  Что такое "сырцо-индекс" ?
Ничего не понятно...

примера ради: одна прокся оперирует данными роли ДисплэйРоле, другая прокся - данными
роли ЭдитРоле. соответственно, каждый индекс будет возвращать на ДисплэйРоле, например, название значения, а на ЭдитРоле - само значение...или наоборот

Что значит "оперирует данными роли..." ?  Каждый из прокси передаёт/получает данные только для одной какой-то роли, а передачу/приём данных для других ролей игнорирует ?

или же вообще провести свои роли. в таком случае та же таблмодель тебе даст массив не двумерный, а размерностью [столбцов * строк * кол-во уникальных ролей]

xep, у меня имена параметров указаны в горизонтальном заголовке таблицы. В первой строке таблицы указаны первые значения для всех параметров, во второй - вторые и т.д. В каждой ячейке расположено n-е значение (n-строка) некоторого параметра. Посему дополнительные роли для ячеек мне не нужны и двумерного массива будет достаточно.
Да и вообще задача заключается в том, что для одного и того же индекса и для одной и той же роли должны возвращаться/передаваться разные данные для табличного представления и древовидного представления.
Я не понимаю твою мысль. Если к стандартным ролям DisplayRole, EditRole, ToolTipRole и т.д., соответствующих табличному представлению, ввести дополнительные роли TreeDisplayRole, TreeEditRole, TreeToolTipRole и т.д. для древовидного представления, то никаких промежуточных моделей или прокси-моделей не понадобится - общая модель M при получении запроса будет исходить из ролей: если роли DisplayRole, EditRole, ToolTipRole и т.д., то возвращаем данные для табличного представления, если TreeDisplayRole, TreeEditRole, TreeToolTipRole и т.д., - для древовидного. Да и вообще, такая схема ролей - чушь какая-то.

плюсы: модели срать с прибором на то, кто её пользует, в частности, её же можно использовать в связке с любыми кутэшными вьюхами; не надо "расширять интерфейс"; перестраивать индексы придётся только при скрытии строк/столбцов (прокси-модели это умеют и без тебя)

Т.е. ставку в отношении плюсов делаешь на функциональность прокси-моделей. Но у меня по-любому перед представлениями будут стоять прокси-модели для фильтрации и сортировки данных. В случае чего, можно будет "перестраивать индексы придётся ... при скрытии строк/столбцов" этими прокси-моделями. А запихивать их функциональность по сортировке/фильтрации в прокси-модели P_table и P_tree, работающих с общей моделью M - не совсем правильно (т.е. разделение по функциональности в силу сильного различия их функций).

в идеале можно обойтись только наследованием модели эМ, а проксям тупо указать роль, с которой забирать дату по сырцо-индексам

Что значит "тупо указать роль, с которой забирать дату по сырцо-индексам" ?

из минусов: если в дереве действительно древовидное отображение (больше 1-2 дочерних нод), таблмодель в качестве модели эМ плохо подходит, т.к. будет ассертить на валидные парентИндексы

Не понял мысль. Мне по-любому придётся создавать две структуры данных: для таблицы (например, массив) и для дерева. При этом если общая модель будет основана на таблице или дереве, то по-любому придётся анализировать индексы и роли и по ним определять, от кого пришёл запрос - от таблицы или от дерева.

Таким образом, пока не указано ни одно серьёзное преимущество в пользу прокси-моделей P_tree и P_table по отношению к обычным моделям M_tree и M_table. Кроме того, что в прокси-моделях по-любому придётся реализовывать чистые виртуальные методы (не зависимо от необходимости этих методов), "заточку" этих прокси-моделей под дерево и под таблицу придётся реализовывать самому, поскольку QAbstractProxyModel наследуется от QAbstractItemModel, тогда как QAbstractTableModel уже имеет такую "заточку" под таблицу (ну а для дерева - также QAbstractItemModel)...
Пока только минусы...

[Cyrax]

Tonal, твой вариант пока лидирует.
Поскольку везкие аргументы в пользу прокси пока отсутствуют, то представляется такая схема:
- общий класс с данными, работающий с БД и содержащий в себе 2 структуры данных: табличную (для хранения значений параметров, отображаемых табличным представлением) и древовидную (для хранения иерархии, имён и характеристик параметров, отображаемых в древовидном представлении)
- две модели M_table (наследник QAbstractTableModel) и M_tree (наследник QAbstractItemModel)
- две прокси-модели P_tree и P_table, сортирующие и фильтрующие данные
- два представления V_tree и V_table
Собственно, отличная реализация принципа "разделения обязанностей"...

[Tonal]

Общий класс у нас обычно строиться таким образом:
Хеш объектов по id-у (у каждого объекта есть своё уникальный id) + несколько дополнительных структур (индексов) для быстрой индексации по выбранным атрибутам, или навигации по дереву подчинённости (если есть).
Каждый такой индекс содержит указатели на объекты из основного хеша.