Qtitan - third-party data Grid для Qt

[sadhu]

Я возможно не прав. Но изменяющаяся сущность в данном случае "фильтр", так почему бы его не инкапсулировать и не дать пользователю
создавать пользовательские фильтры, ещё можно предоставить ряд самых популярных предопределённых фильтров. Сам компонент я не пробовал по этому  предложить точный код не смогу
но можно определить примерно такой интерфейс:

Код:

//интерфейсный класс
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]

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

В моем понимании в 90% случаев применения подобного виджета речь будет идти именно об SQL источниках. Те же DevExpress упоминают  об "unbound mode" (не SQL режиме) как об исключительном случае. МНЕ ЛИЧНО такой навороченный грид с фильтрацией и группировкой да ещё и за деньги (авторы же собираются на нём зарабатывать?) мог заинтересовать бы ИСКЛЮЧИТЕЛЬНО применительно к SQL. Существующий вариант и так требует несоизмеримо бОльшего объёма тупого ручного кодирования по сравнению с тем же DevExpress (как в Delphi, так и в .Net вариантах), поэтому любое дополнительное возлагание на пользователя однотипных механических задач, как мне кажется, бонусов авторам не принесут.

[break]

В моем понимании в 90% случаев применения подобного виджета речь будет идти именно об SQL источниках.

И что если даже так, надо хардкодить неправильные вещи нарушая тем самым саму парадигму модель - вьев ? И забить на 10% остальных случаев?

Существующий вариант и так требует несоизмеримо бОльшего объёма тупого ручного кодирования по сравнению с тем же DevExpress (как в Delphi, так и в .Net вариантах), поэтому любое дополнительное возлагание на пользователя однотипных механических задач, как мне кажется, бонусов авторам не принесут.

А это глупости - вам никто не запрещает 1 раз написать и оформить как класс или процедуру код модифицирующий SQL запрос, который будет вешаться на сигнал от грида. Конечно соответствующие утилиты могут создать и разработчики вьюва, но на мой взгляд все это не сложно и вполне можно сделать самому 1 раз и потом много раз использовать - вы ведь не считаете сложностью устанавливать на каждый экземпляр грида коннект к слоту с обработкой фильтра?

[BigZ]

Вариант реализации с сигналом или без него одинаковы плохи. Так-как подразумевают
модификацию модели, подключенной к гриду. К этой модели могут быть подключены другие гриды или чарты. В результате установка фильтра приведёт к изменению в всех вью. Это не приемлемо.

[xokc]

И что если даже так, надо хардкодить неправильные вещи нарушая тем самым саму парадигму модель - вьев ? И забить на 10% остальных случаев?

Речь идёт не об этом, а о том, что разработчик коммерческого виджета может и должен максимально упростить жизнь большинству своих клиентов. Как он это сделает - выпустит 2 наследника одного виджета (для SQL источника и нет) или как-нибудь по-другому - это его выбор, но загрузка ВСЕГО SQL набора данных на клиент только для того, чтобы потом в результате фильтрации вывести одну (!!!) строку - это абсолютное зло.

Конечно соответствующие утилиты могут создать и разработчики вьюва, но на мой взгляд все это не сложно и вполне можно сделать самому 1 раз и потом много раз использовать

Глупости - это заплатить 599$ за виджет и потом его допиливать напильником. Коммерческие библиотеки мною приобретаются не потому, что я сам не могу повторить их функционал, а прежде всего потому, что у меня нет времени на его реализацию.

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

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

[xokc]

К этой модели могут быть подключены другие гриды или чарты. В результате установка фильтра приведёт к изменению в всех вью. Это не приемлемо.

Почему? На мой взгляд вполне логичное поведение.
Кстати, QtitanDataGrid1.1_vs2008_demo.zip на сайте похоже битый. Качал три раза - всё время "неожиданный конец архива".

[BigZ]

По той причине, что в одном вью хочется фильтровать по дате, а в другом по сумме.

[xokc]

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

[BigZ]

Тогда встаёт вопрос синхронизации между двумя этими моделями. В одну добавил нужно, чтобы в другую тоже.

[BigZ]

Кстати, QtitanDataGrid1.1_vs2008_demo.zip на сайте похоже битый. Качал три раза - всё время "неожиданный конец архива".

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

[xokc]

По прямой скачивается нормально. По "кривым" недокачивается - причем, каждый раз одинаково.

[xokc]

Тогда встаёт вопрос синхронизации между двумя этими моделями. В одну добавил нужно, чтобы в другую тоже.

Ну так ведь опять же при работе с БД вопрос синхронизации стоит постоянно и бесконечно: а если другой пользователь, на другом компе, с другой программы изменил запись? Для борьбы с этим как минимум кнопку refresh придумали, а уж события об изменении данных реализованы не только на уровне модели, но и даже до некоторых СУБД добрались. Что уж тут разработчик сам свои собственные модели не синхронизирует?

[BigZ]

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

[xokc]

Пусть будет столько вызовов, сколько нужно - сервер на то и сервер, чтобы у него регулярно что-нибудь спрашивали. Во-первых, тут уже я сам буду контролировать необходимость обновлений и проектировать GUI клиента с учетом этих моментов. Главное, же что в случае реализации фильтрации на сервере (к каким бы тонкостям это не приводило при реализации клиента) я имею возможность строить реально тонкий клиент, а не монстроподобное приложение с диким потреблением памяти. Впрочем, тут уж разработчику самому решать на какой рынок он позиционирует свой продукт - клиент/серверных или десктопных приложений. Я бы на его месте постарался откусить и там и там.

[BigZ]

Коллеги, выпустили очередную версию QtitanDataGrid. В этой версии выполнена поддержка Mac OS X. Кроме этого
реализован необычный эффект, который позволяет скролировать очень большие таблицы с данными без задержек.
Оценочная версия доступна на сайте http://www.devmachines.com