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

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

Страниц: 1 ... 4 5 [6] 7   Вниз
  Печать  
Автор Тема: Отчетные формы в Qt?  (Прочитано 89333 раз)
ритт
Гость
« Ответ #75 : Июль 20, 2008, 15:51 »

а что, есть готовое? Улыбающийся
Записан
ритт
Гость
« Ответ #76 : Июль 27, 2008, 22:47 »

почему же? думаю, заинтересованы многие...со "стимулом" наверное проблематичнее будет )
Записан
ритт
Гость
« Ответ #77 : Июль 27, 2008, 23:43 »

думаю, форумчане в силах помоч советом/кодом...с QtScript особых пролем не должно возникнуть - если работал с жабаскрипт, увидишь, что не сильно отличается
лично мне импонирует проект exaro, но уж больно там всё криво реализовано...недопиленная система плагинов, недопиленный дизайнер, слабые возможности для работы с исходными данными (из источников только статика, запрос к бд и скрипты)...
к сожалению, на данный момент это - лучшее, что я смог найти для кутэ4...

если у тебя действительно есть время и желание заниматься этим, ты начни и создай об этом ветку в "компонентах" - возможно, народ подтянется по ходу...
Записан
ритт
Гость
« Ответ #78 : Июль 28, 2008, 01:05 »

_персонально_меня_ интересует возможность загрузки данных из абстрактного источника - текста, запроса, модели, файла - по примеру абстрактной модели кутэ; возможность выгружать данные в произвольных форматах; возможности гибкой масштабируемости; предпросмотр отчётов; возможность связывать разнородные отчёты между собой...думаю, этот список ещё можно дополнять и дополнять, но на данный момент я не встречал ни одного движка отчётов (под кутэ4), который умел хотя бы это.

мне представляется для принципиально разных прототипа:
* шаблоны в хмл; ядро, система расширений и рендер отдельной либой, дизайнер - отдельным приложением или либой; скриптованный язык мог бы опционально расширять функциональность движка (тем-более, что в кутэскрипт можно использовать свои независимые "плагины") и быть реализован в виде дополнительного плагина (пример: exaro)
* шаблоны, связки данных и т.п. на скриптовом языке, встроенном в ядро, которое расширяется как бинарными модулями, так и библиотеками на поддерживаемых скрипт.языках; ядро == рендер, дизайнер == гуи + враппер над рендером (пример: nsis - не в тему, но яркий представитель)

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

в любом случае при качественном подходе из гомна можно сделать конфетку...а можно и наоборот...
« Последнее редактирование: Июль 29, 2008, 04:05 от Константин » Записан
ритт
Гость
« Ответ #79 : Июль 29, 2008, 04:05 »

мм...пока вспомнил, добавлю...
вещи, которые часто бывают чуть ли не необходимыми, и отсутствие которых в движке отчётов прямо-таки раздражает:
* часто движок требует _собственного_ соединения с бд - т.е. нужно указать все параметры соединения с бд, в т.ч. и пароль, который по-умному вообще бы не хранить. приходится всяко хитрить, хотя есть штатная возможность передать имя соединения или клонировать соединение и передать инстанцию прямо движку;
* допустим, есть у нас здоровая модель, заполненная множеством запросов к бд, с подготовленными значениями, цветами и т.д. - жутко напрягает, когда для отчёта нужно повторять все эволюции заново, хотя можно было бы просто указать на эту модель;
* довольно распространённая ситуация: метаинфа о файлах (картинках, например) хранится в табличке бд (возможно, и сами картинки), а в других табличках имеются ссылки на данную таблицу - такие поделки, как exaro, без напильника будут упорно показывать дырки от бублика там, где должны быть картинки. либо же придётся такие запросы делать сложными, что плохо влияет на бд-независимость

если вспомнится ещё что-то, дополню этот пост...

trdm, что ты решил в итоге по поводу?
Записан
vaprele07
Гость
« Ответ #80 : Июль 29, 2008, 05:02 »

ksvg2 порт из webkit + inkscape Улыбающийся и все отчеты. Можно слепить свой свг-едитор. Для связывания xml-bd-model-view используй QSimpleXmlNodeModel.
Записан
ритт
Гость
« Ответ #81 : Июль 29, 2008, 05:29 »

жестоко
Записан
Tonal
Гость
« Ответ #82 : Июль 30, 2008, 07:32 »

Не надо бинарный.
1) Его трудно читать/писать сторонними утилитами
2) Его не удобно расширять/изменять при развитии
3) С ним неудобно работать в системах контроля версий (как сравнить 2 версии шаблона отчёта)

XML всяко лучше по всем этим пунктам.
Записан
Tonal
Гость
« Ответ #83 : Июль 30, 2008, 07:40 »

Ну и забор данных, IMHO, лучше сразу сделать над классом:
Код:
struct GetData {
  QString value(const QString& name) = 0;
  QString value(const QString& name, unsigned row) = 0;
}
Ну или возвращать QVariant вместо QString-а, чтобы было удобнее потом скриптование вставлять. Улыбающийся
« Последнее редактирование: Июль 30, 2008, 09:47 от Tonal » Записан
Alex03
Гость
« Ответ #84 : Июль 30, 2008, 08:37 »

XML всяко рулит. Ещё бы какойнить общеупотребимый/стандартизованный формат файла шаблона отчёта (тогда от дизайнера можно отказаться, по крайней мере на начальном этапе)!

А чтобы начать создавать действительно хороший генератор отчётов очень полезно изучить что существует по этой теме.
Т.е. всякие FastReport, CrystalReport, что там в 1С, MS Access кстати тоже, и т.д. и т.п.
А ещё лучше иметь опыт создания реальных, желательно сложных, отчётов в этих системах. Тогда будет представление о том что нужно пользователю, и не будет горьких разочарований по поводу того что выбранная на начальном этапе архитектура не позволяет делать чтото дальше.

Записан
ритт
Гость
« Ответ #85 : Июль 30, 2008, 09:03 »

по-моему, аналог doc->assignValue("Caption","Отчет по продажам."); можно и хтмлкой забацать с финальной заменой %%Caption%% на её значение - как-то не Ъ
а как таким макаром создать, скажем, табличку простых чисел от 1 до 65535? Улыбающийся
особенно, если простые числа уже посчитанны и внесены в модель. делать for(int i = 0; i < model->columnCount(); ++i) doc->assignValue(QString("i%1").arg(i), model->data(model->index(i, 0)).toString()); , а в шаблоне предусмотреть заглушку на 64К строк?
а это тривиально бы выполнилось функцией на кутэскрипте, в которую передавался бы указатель на модель...конечно, если бы скриптовые функции можно было хранить/устанавливать в шаблон
Записан
Пантер
Administrator
Джедай : наставник для всех
*****
Offline Offline

Сообщений: 5876


Жаждущий знаний


Просмотр профиля WWW
« Ответ #86 : Июль 30, 2008, 13:13 »

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

1. Qt - Qt Development Frameworks; QT - QuickTime
2. Не используйте в исходниках символы кириллицы!!!
3. Пользуйтесь тегом code при оформлении сообщений.
ритт
Гость
« Ответ #87 : Июль 30, 2008, 16:36 »

я уже писал ранее - если делать ядро изначально основанное на скриптовании, гибкость будет максимальной
кутэскрипт даёт огромное преимущество над "внешними" интерпретируемыми языками: во-первых, кутэскрипт одинаково можно подружить с жабаскриптом, вбс или луа; во-вторых, кутэскрипт имеет доступ к сущностям приложения на кутэ, что делает выборку из запроса и/или модели не сложнее функций на самом скрипте
про хмл - посмотри всё тот же ексаро - там тупо кастомизированные уишки дизайнера - привычно и читабельно
Записан
Tonal
Гость
« Ответ #88 : Июль 30, 2008, 16:39 »

Пришла тут идейка задействовать для отчётника python + django.
Т.е. дезайнер будет сохранять шаблон в формате django.
Дальше, с помощью PythonQt пускаем рендер шаблона в html.
А уже html можно и показывать и печатать. Улыбающийся
Записан
ритт
Гость
« Ответ #89 : Июль 30, 2008, 18:35 »

работа с куобъектами из кутэскрипта не слишком отличается от работы с объектами посредством мета(объектов|методов|проперти)
думаю, достаточно будет реализовать парсинг/исполнение скриптов в контексте по типу твоего примера с doc->outputSection("Title");
ну, например, для шаблона на основе хмл:
Цитировать
<section name="Title">Example ver.<script>appVesrsion();</script></section>
/* я не привожу конкретный пример - это некая абстракция с потолка */
вообще, по теме шаблонов/фигур/скриптов мне импонирует принцип свг, где ресурсы могут быть встроенными или внешними, что часто оказывается чрезвычайно удобно

а с doc->outputSection("Title") мне не ясен такой момент: выходит, мы должны знать названия секций в шаблоне и поочерёдно эти секции активировать? это чем-либо оправдано или тоже абстракция?
« Последнее редактирование: Июль 30, 2008, 18:38 от Константин » Записан
Страниц: 1 ... 4 5 [6] 7   Вверх
  Печать  
 
Перейти в:  


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