Qtitan - third-party data Grid для Qt

[break]

Наилучшей гарантией ... является наличие исходных кодов

Золотые слова - и

Стало быть опыт у разработчика применяющего ваши наработки должен быть не маленьким.....
....
Если это так, то скорее всего для себя он уже сделал, что-то подобное. Но это не его собственность, а работодателя.

это не совсем верно - т.к. опыт то может быть - но может совсем не быть времени на то что бы писать всякие гриды, а вот если затаилась ошибка - то сесть разобраться и пофиксить ее можно вполне когда есть исходники, особенно если исходники грамотно оформлены и написаны людьми для людей.

Но не так много людей жаждют разбираться в потрохах Qt, а ведь там нет того, что есть у вас.

Опять же Qt библиотека - Грид конкретный компонент с которым при необходимости можно будет вполне разобораться при наличии исходников, даже не влезая в глубокие потроха Qt.

Думаю наличие исходников самый лучший гарант, даже если контора разработавшая компонент закроется - можно будет что-то сделать!

[BigZ]

Коллеги, вышла след. версия QtianDataGrid1.1. Релиз в основном направлен на исправление выявленных
ошибок. Из новшеств добавлен режим группировки ms – office. Переписан режим работы с relation моделями. Появилась возможность сохранить и загрузить из XML лайауат расположения колонок и бандов грида.
http://www.devmachines.com

[xokc]

Когда фильтрация и вложенные таблицы появятся ?

[BigZ]

Фильтрация, со всеми диалогами, ориентировочно на февраль. Иерархические вью - март-апрель.

[xokc]

Фильтры будут как у DevExpress только на клиентской стороне работать?

[BigZ]

А какие есть варианты? Что подразумевается под клиентской стороной?

[xokc]

У DevExpress вся фильтрация происходит только на клиентской машине, когда считываются ВСЕ данные с сервера и только часть из них (в соответствии с условиями фильтра) отображается. Для больших наборов данных это приводит как минимум к существенным тормозам и расходам памяти на клиенте (даже если условиям фильтра удовлетворяет только одна запись). Оптимальным видится преобразование условий фильтров (хотя-бы частично) в SQL выражения и, таким образом, фильтрация данных прямо на сервере. Иначе трудно бывает объяснять заказчику почему на отображении пары записей уходят все ресурсы довольно мощного компа (про тонкости реализации/смену парадигмы отображения записей он слышать не хочет). Кстати, то же самое касается и группировок. Неплохо было-бы иметь режим отображения, когда подчинённые записи запрашиваются с сервера только по мере необходимости - при раскрытии родительской.

[BigZ]

Идея здравая, но пока не видно путей, как это можно красиво реализовать.
Грид привязывается к абстрактному QAbstractItemModel и перейти от неё к SQL достаточно проблематично. Приходится оперировать только теми методами, которые есть. Там нет ни какой зацепки, чтобы это сделать. Если у тебя есть схема, которая
позволяет реализовать то, что ты написал, пришли мне её на мыло, обсудим. Если она покажется интересной я добавлю её к реализации.

[break]

А может добавить флаг в грид SQL Data source и если он установлен то производить фильтрацию через модификацию SQL запросов (делая касты AbstractModel в SQLQueryModel), если не установлен то стандартным способом.

[BigZ]

Я склоняюсь к идеи выстрелить перед наложением фильтра сигналом, в обработчике
которого, пользователь сможет сам выполнить необходимые SQL манипуляции с моделью.
Модель и настройки фильтра ему придут.

[xokc]

зацепки, чтобы это сделать. Если у тебя есть схема, которая
позволяет реализовать то, что ты написал, пришли мне её на мыло, обсудим. Если она покажется интересной я добавлю её к реализации.

Я выходец из Delphi и как это можно было бы сделать на их DataSource примерно себе представляю. В MVC же от Qt я не чувствую себя достаточно уверенным, чтобы предлагать варианты подобных реализаций.

[BigZ]

Напиши в термах дельфи, я пойму. Можно кратко, чтобы было несколько мнений.

[xokc]

Ну для начала разъясните мне, существует ли принципиальная проблема в автоматическом преобразовании "строки" фильтра в текст с синтаксисом SQL выражения "WHERE"? Если такой проблемы нет, то я бы в Delphi, например, в случае наследования DataSet от TQuery (можно проверять наличие и популярных других вариантов типа TAdoQuery, TFIBDataSet и т.п.), после формирования пользователем фильтра, преобразовывал бы его к SQL, заменял в исходном SQL тексте утверждение WHERE, запоминал текущую строку в гриде, переоткрывал запрос (ну или делал бы FullRefresh) и позиционировался на "правильную" запись.
Для группировок схема примерно такая же. Для каждой группировки формируется SQL кусок GROUP BY по полю группировки. При этом на OnExpand для узлов группировок вешаются процедуры догрузки данных из БД (c фильтром WHERE на поле группировки), а при первичном отображении грида загружаются только записи самого верхнего уровня. Остальные загрузятся сами по мере разворачивания полей группировок.
Из минусов решения вижу возможность наличия тормозов на сервере при большом объеме БД, если производится фильтрация/группировка по неиндексированному полю. Но в этом случае виноват будет не столько виджет, сколько программер/разработчик БД.

[break]

Если я правильно понял ребята пока пишут вьюв а не модель и этот вьюв не обязательно должен работать с SQL моделью. То есть источник данных может быть таким где SQL фильтрация с модификацией запросов вообще не при чем. Наверное это и является проблемой т.к. не хочется хардкодить в гриде завязку на SQL -ные модели.

Если не правильно понял поправьте...

[BigZ]

Ну для начала разъясните мне, существует ли принципиальная проблема в автоматическом преобразовании "строки" фильтра в текст с синтаксисом SQL выражения "WHERE"?

Я тут проблем не вижу. Но по сути ты предложил то, что предлагал break постом выше. Захардкодить знания о специфичном SQL провайдере во вью. Это не кажется правильным.

Если не правильно понял поправьте...

Всё так.