Russian Qt Forum
Ноябрь 13, 2019, 17:00 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: 1 2 [3] 4 5   Вниз
  Печать  
Автор Тема: Qtitan - third-party data Grid для Qt  (Прочитано 38796 раз)
break
Гипер активный житель
*****
Offline Offline

Сообщений: 846


Просмотр профиля
« Ответ #30 : Сентябрь 01, 2010, 00:18 »

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

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

Думаю наличие исходников самый лучший гарант, даже если контора разработавшая компонент закроется - можно будет что-то сделать!
Записан
BigZ
Гость
« Ответ #31 : Декабрь 09, 2010, 07:31 »

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

Сообщений: 970



Просмотр профиля
« Ответ #32 : Декабрь 10, 2010, 15:58 »

Когда фильтрация и вложенные таблицы появятся ?
Записан
BigZ
Гость
« Ответ #33 : Декабрь 10, 2010, 17:47 »

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

Сообщений: 970



Просмотр профиля
« Ответ #34 : Декабрь 10, 2010, 22:33 »

Фильтры будут как у DevExpress только на клиентской стороне работать?
Записан
BigZ
Гость
« Ответ #35 : Декабрь 11, 2010, 09:29 »

А какие есть варианты? Что подразумевается под клиентской стороной?
Записан
xokc
Птица говорун
*****
Offline Offline

Сообщений: 970



Просмотр профиля
« Ответ #36 : Декабрь 12, 2010, 18:02 »

У DevExpress вся фильтрация происходит только на клиентской машине, когда считываются ВСЕ данные с сервера и только часть из них (в соответствии с условиями фильтра) отображается. Для больших наборов данных это приводит как минимум к существенным тормозам и расходам памяти на клиенте (даже если условиям фильтра удовлетворяет только одна запись). Оптимальным видится преобразование условий фильтров (хотя-бы частично) в SQL выражения и, таким образом, фильтрация данных прямо на сервере. Иначе трудно бывает объяснять заказчику почему на отображении пары записей уходят все ресурсы довольно мощного компа (про тонкости реализации/смену парадигмы отображения записей он слышать не хочет). Кстати, то же самое касается и группировок. Неплохо было-бы иметь режим отображения, когда подчинённые записи запрашиваются с сервера только по мере необходимости - при раскрытии родительской.
« Последнее редактирование: Декабрь 12, 2010, 18:05 от xokc » Записан
BigZ
Гость
« Ответ #37 : Декабрь 12, 2010, 18:28 »

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

Записан
break
Гипер активный житель
*****
Offline Offline

Сообщений: 846


Просмотр профиля
« Ответ #38 : Декабрь 13, 2010, 14:59 »

А может добавить флаг в грид SQL Data source и если он установлен то производить фильтрацию через модификацию SQL запросов (делая касты AbstractModel в SQLQueryModel), если не установлен то стандартным способом.
Записан
BigZ
Гость
« Ответ #39 : Декабрь 13, 2010, 17:08 »

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

« Последнее редактирование: Декабрь 13, 2010, 17:13 от BigZ » Записан
xokc
Птица говорун
*****
Offline Offline

Сообщений: 970



Просмотр профиля
« Ответ #40 : Декабрь 13, 2010, 21:22 »

зацепки, чтобы это сделать. Если у тебя есть схема, которая
позволяет реализовать то, что ты написал, пришли мне её на мыло, обсудим. Если она покажется интересной я добавлю её к реализации.
Я выходец из Delphi и как это можно было бы сделать на их DataSource примерно себе представляю. В MVC же от Qt я не чувствую себя достаточно уверенным, чтобы предлагать варианты подобных реализаций.
Записан
BigZ
Гость
« Ответ #41 : Декабрь 13, 2010, 23:31 »

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

Сообщений: 970



Просмотр профиля
« Ответ #42 : Декабрь 14, 2010, 21:43 »

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

Сообщений: 846


Просмотр профиля
« Ответ #43 : Декабрь 15, 2010, 03:54 »

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

Если не правильно понял поправьте...
Записан
BigZ
Гость
« Ответ #44 : Декабрь 15, 2010, 12:26 »

Ну для начала разъясните мне, существует ли принципиальная проблема в автоматическом преобразовании "строки" фильтра в текст с синтаксисом SQL выражения "WHERE"?
Я тут проблем не вижу. Но по сути ты предложил то, что предлагал break постом выше. Захардкодить знания о специфичном SQL провайдере во вью. Это не кажется правильным.
Цитировать
Если не правильно понял поправьте...
Всё так.
« Последнее редактирование: Декабрь 15, 2010, 12:28 от BigZ » Записан
Страниц: 1 2 [3] 4 5   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.049 секунд. Запросов: 22.