Russian Qt Forum

хочу посоветоваться...

стоит задача: тэйблмодель заполняется исходными данными (Qt::EditRole) из какого-то источника структурированных записей (ну, для упрощения, например, из лог-файла), где значения определённых столбцов закодированы и должны преобразовываться в какие-то более читабельные для пользователя данные (Qt::DisplayRole) (подобие реляционной таблмодели, но всё более сложно, чем заложено в кутёвом функционале)
причём, нет смысла декодирование индексов в читабельный вид кодить в наследнике таблмодели, т.к.:
1. структура записей динамична и может изменяться от версии к версии;
2. кроме простой перекодировки ид=>имя предполагается как минимум пол-дюжины перекодировок других видов (ну, чисто для примера - таймстамп=>датавремя;строка_на_аглицком=>строка_на_русском и т.п.).

до сих пор самой умной мыслью, что посетила меня по поводу, было реализовать наследника таблмодели (аналог реляционной таблмодели с той разницей, что исходные данные поступают в Qt::EditRole, а не Qt::DisplayRole, как в QSqlRelationalTableModel + аналог QSqlRelation с виртуальными гетером и сетером значения строки N, что позволит переопределять обработчик для Qt::DisplayRole)

возможно, у кого-то есть идеи или кто-то заинтересован в подобной модели - буду признателен за любые комментарии (конструктивного содержания)

зы. то, что получится в результате, планирую выложить в "компонентах"

Я в своём  наследнике класса модели вместо виртуальных функций геттеров и сеттеров сделал сигналы

void onGetData(QField *fld, QVariant & value, int nRole) const;
void onSetData(QField *fld, QVariant & value, int nRole) const;

QField *fld можно заменить на const QModelIndex & index

оформил эту модель в библиотеку, ессно.

в функции модели QVariant data(...) присваиваю значение value и перед return высылаю сигнал onGetData. Заинтересованная программа его ловит, анализирует и подменяет value, в случае необходимости.

Точно также и с сигналом onSetData.

В зависимости от роли, программа может подменить вообще всё, что угодно (цвет, шрифт, иконку в ячейке, ...), невзирая на предложения модели и не наследуясь от неё.

перепробовал разные варианты - и сигналы, как у Змеище, и наследник модели, как в первом посте - получается одно только низкопроизводительное неудобное гомнецо...основная причина - оба варианта конечны - если требуется отнаследоваться от такой модели, приходится копипастить код data/setData

таким вот эмпирическим путём установил, что самые удобные (в плане использования и последующего наследования) варианты:
* если модифицировать данные нужно только для отображения, наследуемся от айтемделегата и перегружаем displayText/initStyleOption;
* если модифицировать данные нужно и для отображения, и для сортировки/фильтрации/использования_из_модели_"как есть", наследуемся от проксимодели и перегружаем data/setData таким образом, чтобы для определённых ролей на выходе data получалась готовая к работе строка;
+ оба эти варианта потенциально производительнее первых двух