Russian Qt Forum
Апрель 26, 2024, 15:59 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

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

Russian Qt Forum > Forum > Qt > Дополнительные компоненты > Qtitan - third-party data Grid для Qt
Страниц: 1 2 3 [4] 5   Вниз
« предыдущая тема следующая тема »
  Печать  
Автор Тема: Qtitan - third-party data Grid для Qt  (Прочитано 67564 раз)
sadhu
Гость
« Ответ #45 : Декабрь 15, 2010, 13:46 »
Я возможно не прав. Но изменяющаяся сущность в данном случае "фильтр", так почему бы его не инкапсулировать и не дать пользователю
создавать пользовательские фильтры, ещё можно предоставить ряд самых популярных предопределённых фильтров. Сам компонент я не пробовал по этому  предложить точный код не смогу
но можно определить примерно такой интерфейс:
Код:
//интерфейсный класс
class AFilter:bublic QObject
{
  Q_OBJECT
public:
 virtual void setup()=0;//запускает процесс фильтрации
 bool isUsed() const;
 TitanDataGrid * grid() cont;

 public slots:
 void setUsed(bool used);
signals:
 void filterChanged();
};
а пользователь имея доступ к гриду, а значит ко всем его сойствам получает возможность осуществлять сколь-угодно сложную фильтрацию.

Хотя лично я за использование кастомных прокси-моделей ибо фильтр подобного рода можно применить к любому представлению , фильтрацию данных в этом случае выполняет сам поставщик данных, что гораздо приятнее и избавляет от необходимости поддержки фильтрции в представлении.
Записан
xokc
Птица говорун
*****
Offline Offline

Сообщений: 976



Просмотр профиля
« Ответ #46 : Декабрь 15, 2010, 23:05 »
Цитата: break от Декабрь 15, 2010,  03:54
То есть источник данных может быть таким где SQL фильтрация с модификацией запросов вообще не при чем.
В моем понимании в 90% случаев применения подобного виджета речь будет идти именно об SQL источниках. Те же DevExpress упоминают  об "unbound mode" (не SQL режиме) как об исключительном случае. МНЕ ЛИЧНО такой навороченный грид с фильтрацией и группировкой да ещё и за деньги (авторы же собираются на нём зарабатывать?) мог заинтересовать бы ИСКЛЮЧИТЕЛЬНО применительно к SQL. Существующий вариант и так требует несоизмеримо бОльшего объёма тупого ручного кодирования по сравнению с тем же DevExpress (как в Delphi, так и в .Net вариантах), поэтому любое дополнительное возлагание на пользователя однотипных механических задач, как мне кажется, бонусов авторам не принесут.
Записан
break
Гипер активный житель
*****
Offline Offline

Сообщений: 846


Просмотр профиля
« Ответ #47 : Декабрь 15, 2010, 23:46 »
Цитировать
В моем понимании в 90% случаев применения подобного виджета речь будет идти именно об SQL источниках.
И что если даже так, надо хардкодить неправильные вещи нарушая тем самым саму парадигму модель - вьев ? И забить на 10% остальных случаев?

Цитировать
Существующий вариант и так требует несоизмеримо бОльшего объёма тупого ручного кодирования по сравнению с тем же DevExpress (как в Delphi, так и в .Net вариантах), поэтому любое дополнительное возлагание на пользователя однотипных механических задач, как мне кажется, бонусов авторам не принесут.
А это глупости - вам никто не запрещает 1 раз написать и оформить как класс или процедуру код модифицирующий SQL запрос, который будет вешаться на сигнал от грида. Конечно соответствующие утилиты могут создать и разработчики вьюва, но на мой взгляд все это не сложно и вполне можно сделать самому 1 раз и потом много раз использовать - вы ведь не считаете сложностью устанавливать на каждый экземпляр грида коннект к слоту с обработкой фильтра?
Записан
BigZ
Гость
« Ответ #48 : Декабрь 16, 2010, 10:50 »
Вариант реализации с сигналом или без него одинаковы плохи. Так-как подразумевают
модификацию модели, подключенной к гриду. К этой модели могут быть подключены другие гриды или чарты. В результате установка фильтра приведёт к изменению в всех вью. Это не приемлемо.
Записан
xokc
Птица говорун
*****
Offline Offline

Сообщений: 976



Просмотр профиля
« Ответ #49 : Декабрь 16, 2010, 21:28 »
Цитата: break от Декабрь 15, 2010,  23:46
И что если даже так, надо хардкодить неправильные вещи нарушая тем самым саму парадигму модель - вьев ? И забить на 10% остальных случаев?
Речь идёт не об этом, а о том, что разработчик коммерческого виджета может и должен максимально упростить жизнь большинству своих клиентов. Как он это сделает - выпустит 2 наследника одного виджета (для SQL источника и нет) или как-нибудь по-другому - это его выбор, но загрузка ВСЕГО SQL набора данных на клиент только для того, чтобы потом в результате фильтрации вывести одну (!!!) строку - это абсолютное зло.

Цитата: break от Декабрь 15, 2010,  23:46
Конечно соответствующие утилиты могут создать и разработчики вьюва, но на мой взгляд все это не сложно и вполне можно сделать самому 1 раз и потом много раз использовать
Глупости - это заплатить 599$ за виджет и потом его допиливать напильником. Коммерческие библиотеки мною приобретаются не потому, что я сам не могу повторить их функционал, а прежде всего потому, что у меня нет времени на его реализацию.

Цитата: break от Декабрь 15, 2010,  23:46
вы ведь не считаете сложностью устанавливать на каждый экземпляр грида коннект к слоту с обработкой фильтра
Если за меня это может сделать кто-то другой, то - считаю. У меня достаточно забот и с основным функционалом приложения, чтобы отвлекаться на подобную ерунду.
Записан
xokc
Птица говорун
*****
Offline Offline

Сообщений: 976



Просмотр профиля
« Ответ #50 : Декабрь 16, 2010, 21:32 »
Цитата: BigZ от Декабрь 16, 2010,  10:50
К этой модели могут быть подключены другие гриды или чарты. В результате установка фильтра приведёт к изменению в всех вью. Это не приемлемо.
Почему? На мой взгляд вполне логичное поведение.
Кстати, QtitanDataGrid1.1_vs2008_demo.zip на сайте похоже битый. Качал три раза - всё время "неожиданный конец архива".
« Последнее редактирование: Декабрь 16, 2010, 22:10 от xokc » Записан
BigZ
Гость
« Ответ #51 : Декабрь 16, 2010, 22:10 »
По той причине, что в одном вью хочется фильтровать по дате, а в другом по сумме.
Записан
xokc
Птица говорун
*****
Offline Offline

Сообщений: 976



Просмотр профиля
« Ответ #52 : Декабрь 16, 2010, 22:14 »
С трудом представляю себе такую ситуацию, чтобы на экране было одновременно несколько разных вью от одной модели с разными наборами фильтров. Что мешает при таких желаниях к двум разным вью прицепить две разных модели?
Записан
BigZ
Гость
« Ответ #53 : Декабрь 16, 2010, 22:21 »
Тогда встаёт вопрос синхронизации между двумя этими моделями. В одну добавил нужно, чтобы в другую тоже.
Записан
BigZ
Гость
« Ответ #54 : Декабрь 16, 2010, 22:31 »
Цитата: xokc от Декабрь 16, 2010,  21:32
Кстати, QtitanDataGrid1.1_vs2008_demo.zip на сайте похоже битый. Качал три раза - всё время "неожиданный конец архива".

Странно. Только что проверил, всё хорошо. Может в кеше застрял?
Попробуй по прямой ссылке - http://www.devmachines.com/downloads/QtitanDataGrid1.1_vs2008_demo.zip
Записан
xokc
Птица говорун
*****
Offline Offline

Сообщений: 976



Просмотр профиля
« Ответ #55 : Декабрь 17, 2010, 06:14 »
По прямой скачивается нормально. По "кривым" недокачивается - причем, каждый раз одинаково.
Записан
xokc
Птица говорун
*****
Offline Offline

Сообщений: 976



Просмотр профиля
« Ответ #56 : Декабрь 17, 2010, 20:10 »
Цитата: BigZ от Декабрь 16, 2010,  22:21
Тогда встаёт вопрос синхронизации между двумя этими моделями. В одну добавил нужно, чтобы в другую тоже.
Ну так ведь опять же при работе с БД вопрос синхронизации стоит постоянно и бесконечно: а если другой пользователь, на другом компе, с другой программы изменил запись? Для борьбы с этим как минимум кнопку refresh придумали, а уж события об изменении данных реализованы не только на уровне модели, но и даже до некоторых СУБД добрались. Что уж тут разработчик сам свои собственные модели не синхронизирует?
Записан
BigZ
Гость
« Ответ #57 : Декабрь 18, 2010, 09:49 »
Я понимаю, что технически это решается. Я имел ввиду, что придётся делать два раз рефрешь с двумя моделями.
С одной моделью только один. У тебя будет два серверных вызова.
Записан
xokc
Птица говорун
*****
Offline Offline

Сообщений: 976



Просмотр профиля
« Ответ #58 : Декабрь 18, 2010, 10:55 »
Пусть будет столько вызовов, сколько нужно - сервер на то и сервер, чтобы у него регулярно что-нибудь спрашивали. Во-первых, тут уже я сам буду контролировать необходимость обновлений и проектировать GUI клиента с учетом этих моментов. Главное, же что в случае реализации фильтрации на сервере (к каким бы тонкостям это не приводило при реализации клиента) я имею возможность строить реально тонкий клиент, а не монстроподобное приложение с диким потреблением памяти. Впрочем, тут уж разработчику самому решать на какой рынок он позиционирует свой продукт - клиент/серверных или десктопных приложений. Я бы на его месте постарался откусить и там и там.
Записан
BigZ
Гость
« Ответ #59 : Февраль 10, 2011, 23:54 »
Коллеги, выпустили очередную версию QtitanDataGrid. В этой версии выполнена поддержка Mac OS X. Кроме этого
реализован необычный эффект, который позволяет скролировать очень большие таблицы с данными без задержек.
Оценочная версия доступна на сайте http://www.devmachines.com
Записан
Страниц: 1 2 3 [4] 5   Вверх
  Печать  
« предыдущая тема следующая тема »
 
Перейти в:  


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