Как избавиться от downcast'а в GUI?

Question

[timao]

Есть окно Window, на нём на разных вкладках около полусотни виджетов: QLineEdit, QDateEdit и QComboBox, а точнее собственные классы-наследники.

Суть окна Window:
Открываем окно -> запрос селект из mysql -> заполняем виджеты
Нажимаем кнопку Save -> запрос update в mysql -> закрываем окно

Чтобы не писать логику для каждого отдельного виджета хочется иметь что-то вроде QMap, где первое поле - столбец таблицы mysql. Всё это чтобы заполнять виджеты, сравнивать с первоначальным значением (QWidget::​setProperty), собирать запросы update как-то более централизованно. И код не дублировать.

Мало в жизни писал GUI, а с downcast'а проект начинать не хочется. Спасибо за внимание.

P.S. Кто не знаком с Qt:
QLineEdit, QDateEdit и QComboBox - наследники QWidget, всё это библиотечные GUI классы-виджеты.
QMap - аналог std::map

Answer 1

[jcmvbkbc]

иметь что-то вроде QMap, где первое поле - столбец таблицы mysql.

а второе поле -- указатель на общий интерфейс, назовём его IUpdate, реализованный конкретными классами, знающими о том, как работать с конкретными классами виджетов. Или прямо самими классами виджетов.

Comments

[timao]

Поясните, пожалуйста. Мои классы отнаследованы от базовых (QLineEdit, QDateEdit и QComboBox соответственно). Как сделать им общий интерфейс, если у них родители разные? Оба мои варианта (IUpdate как второй родитель или IUpdate как шаблон класса) не решают проблему.
//прошу прощения, если спрашиваю что-то базовое

[jcmvbkbc]

> IUpdate как второй родитель
timao: ну да, множественное наследование. Почему не решает? И почему вы выбрали этот вариант, вместо отдельных классов знающих о бд и о виджетах?

[timao]

А да, решает. Если честно, до этого момента не думал, что полиморфизм при множественном наследовании работает. Всё встало на свои места. Спасибо.

Не совсем понял второй вопрос. Эти отдельные классы - не наследники базовых виджетов? Protected методы обработки событий мне тоже надо переопределять.

[jcmvbkbc]

> Эти отдельные классы - не наследники базовых виджетов?
timao: нет. В эти классы можно было бы собрать всю логику, касающуюся обновления бд данными из виджетов. Это выглядит более правильно, чем совать эту логику в виджеты, но и немного более многословно. Если нужно делать какие-то действия с бд инициируемые со стороны виджетов, точно так же можно этим классам дать второй интерфейс, обращённый в сторону виджетов.

[timao]

Конкретно в этой задаче общий интерфейс у самописных виджетов будет ограничиваться get/set. Они примитивные. Все запросы к бд выполняет класс-окно. Окон правда похожих на это предостаточно. Буду рад любым наводкам/ссылкам/книгам по реализации вашего способа.

Answer 2

[jkrieger]

Если я правильно понял задачу вам нужен QDataWidgetMapper.

Comments

[timao]

Потрясно! Жалко уже написал велосипед. Если будет время, перепишу на ваш способ. Вообще, стоило догадаться, что идиома модель-представления в qt предусмотрена и для форм. Спасибо.

Answer 3

[Армянское Радио]

Генерируйте ваши полсотни виджетов вместе с запросом, кто вам запрещает? Просто программа должна "знать" чуть больше о структуре данных.

Comments

[timao]

Поясните, пожалуйста. Создать, один раз их написав, не проблема. Хотелось бы потом в цикле по ним ходить. И при генерации запросов (insert и update) получать запрос, написав пару строк, а не перечисляя, боясь забыть, все эти виджеты и их sql поля.

[Армянское Радио]

timao: Создаете массив - {тип виджета, имя колонки, название виджета}
по этому массиву строете запрос и по этому же массиву можно бегать, связав с ним виджеты.

[timao]

По вашему, мы так избавимся от downcast'а?

[Армянское Радио]

timao: Если массив не будет меняться во время работы приложения, собирайте его в кортеж (std::tuple) во время компиляции.

[timao]

Да, это должно сработать, не совсем правда изящно. Большое спасибо!