Отчетные формы в Qt?

[ритт]

а что, есть готовое?

[ритт]

почему же? думаю, заинтересованы многие...со "стимулом" наверное проблематичнее будет )

[ритт]

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

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

[ритт]

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

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

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

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

[ритт]

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

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

trdm, что ты решил в итоге по поводу?

[vaprele07]

ksvg2 порт из webkit + inkscape и все отчеты. Можно слепить свой свг-едитор. Для связывания xml-bd-model-view используй QSimpleXmlNodeModel.

[ритт]

жестоко

[Tonal]

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

XML всяко лучше по всем этим пунктам.

[Tonal]

Ну и забор данных, IMHO, лучше сразу сделать над классом:

Код:

struct GetData {
  QString value(const QString& name) = 0;
  QString value(const QString& name, unsigned row) = 0;
}

Ну или возвращать QVariant вместо QString-а, чтобы было удобнее потом скриптование вставлять.

[Alex03]

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

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

[ритт]

по-моему, аналог 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К строк?
а это тривиально бы выполнилось функцией на кутэскрипте, в которую передавался бы указатель на модель...конечно, если бы скриптовые функции можно было хранить/устанавливать в шаблон

[Пантер]

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

[ритт]

я уже писал ранее - если делать ядро изначально основанное на скриптовании, гибкость будет максимальной
кутэскрипт даёт огромное преимущество над "внешними" интерпретируемыми языками: во-первых, кутэскрипт одинаково можно подружить с жабаскриптом, вбс или луа; во-вторых, кутэскрипт имеет доступ к сущностям приложения на кутэ, что делает выборку из запроса и/или модели не сложнее функций на самом скрипте
про хмл - посмотри всё тот же ексаро - там тупо кастомизированные уишки дизайнера - привычно и читабельно

[Tonal]

Пришла тут идейка задействовать для отчётника python + django.
Т.е. дезайнер будет сохранять шаблон в формате django.
Дальше, с помощью PythonQt пускаем рендер шаблона в html.
А уже html можно и показывать и печатать.

[ритт]

работа с куобъектами из кутэскрипта не слишком отличается от работы с объектами посредством мета(объектов|методов|проперти)
думаю, достаточно будет реализовать парсинг/исполнение скриптов в контексте по типу твоего примера с doc->outputSection("Title");
ну, например, для шаблона на основе хмл:

<section name="Title">Example ver.<script>appVesrsion();</script></section>

/* я не привожу конкретный пример - это некая абстракция с потолка */
вообще, по теме шаблонов/фигур/скриптов мне импонирует принцип свг, где ресурсы могут быть встроенными или внешними, что часто оказывается чрезвычайно удобно

а с doc->outputSection("Title") мне не ясен такой момент: выходит, мы должны знать названия секций в шаблоне и поочерёдно эти секции активировать? это чем-либо оправдано или тоже абстракция?