LimeReport - Open-source Qt генератор отчетов, релиз новой версии 1.5

Выглядит интересно. Есть ли активные пользователи / разработчики(те кто применяет библиотеку)?

На официальном форуме достаточно приличное количество пользователей, причем их сообщество многонационально.

Написал бы что это вообще такое, потому что словосочетание «генератор отчётов» ничего не объясняет.

например, хттп://bolid.ru/about/news/2016/07/12/news_1184.html одни из официально заявивших об использовании

Довольно часто разработчики программного обеспечения сталкиваются с необходимостью презентации данных и вывода их на печать. LimeReport, с помощью встроенного дизайнера, позволяет создавать шаблоны отчётов, на основании которых готовятся печатные формы с возможностью их предварительного просмотра, а также последующего вывода на печать или экспорта в PDF файл. Очевидное преимущество такого подхода в сравнении с генерацией отчёта из кода программы заключается в том, что для изменения внешнего вида печатной формы не требуется перекомпиляция программы, достаточно изменить шаблон документа. Печатные формы LimeReport могут быть полностью самодостаточными, в этих формах можно описать параметры подключения к источнику данных, sql запросы и вид представления данных, единственное, что остаётся приложению - установить значения переменных на осно\-вании, которых будет построен отчёт. Нужно так же отметить, что LimeReport поддерживает использование скриптов в процессе формирования печатной формы, тем самым ещё больше увеличивая гибкость и независимость системы формирования отчётов. Наличие встроенного WYSIWYG дизайнера отчётов позволяет точно расположить элементы отчёта на странице, тем самым сильно упрощая жизнь разработчикам, которым необходимо впечатывать текст в уже существующие бланки.

LimeReport - кросс-платформенная С++ библиотека, написанная с использованием Qt framework и предназначенная для разработчиков программного обеспечения, которые хотят добавить в свое Qt приложение возможность формирования отчетов или печатных форм, генерируемых на основании шаблона. Дизайнер отчетов, входящий в состав этой библиотеки, позволит быстро и интуитивно-понятно сформировать шаблон печатной формы, который может быть сохранен в формате XML и использован в дальнейшем для генерации страниц отчета. Полученные таким образом страницы могут быть направлены на предварительный просмотр, в PDF файл или на принтер. В качестве источника данных поддерживается SQL база данных или данные, переданные из приложения с использованием интерфейса QAbstractTableModel. Также из приложения могут быть проинициализированы переменные, которые доступны в качестве параметров запросов к базе данных. Задача LimeReport - оснастить Ваше приложение функционально-богатым и в тоже время простым в использовании инструментом генерации отчетов, которым смогут пользоваться даже неискушенные в информационных технологиях пользователи.

Я вот зашел на сайт ихний - там все более менее понятно. Не ленись.

Это на сервере можно использовать? В XLSX оно, похоже, не умеет. В таком виде пока не нужно, но если допилят побольше форматов, то станет очень нужно.

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

Премерзкая работёнка такие велогенераторы писать. А писать приходится, ибо из альтернатив велосипеду есть в общем-то лишь репортлаб, но он жутких денег стоит и не всегда есть возможность его в своей системе заюзать.

https://bitbucket.org/rptlab/reportlab/downloads/ src

Нужно, чтобы он брал json/xml/etc макета, «компилировал» его, потом брал json с данными (хоть через stdin/fifo) и быстро собирал pdf'ку. Цель - 5мс на pdf из 10 а4 с кучей таблиц и qr кодов. Можно даже не извращаться с многопотоком. Gui не надо, можно выпилить и сделать сборку *приложения* (не библиотеки) без gui для сервера. Sql вкорячивать тоже не надо, можно сделать выпиливаемым при сборке. Нужно хорошую документацию на макет, чтобы можно было его написать руками без гуя.
Еще раз.
Нужно:
Чисто cli приложение без зависимости от иксовых либ
При запуске с ключём подгружает себе макет отчёта
Через fifo/пайп читает json с данными
В файл пишет pdf, в stdout/stderr ошибки
Описание макета должно быть хорошо задокументировано
Время генерации 10 страничного pdf с данными, штрих кодами и qr кодами должно стремиться к 5-и миллисекундам и меньше
Если останутся силы - поддержка различных форматов odf, xls, doc, etc
Не нужно:
Косплей fastreports и подобного мусора
Ориентированность чисто на десктоп, мышевозов и 2 отчёта в час до принтера

WYSIWYG

Не нужно, разве что для мышевозов. Нужен хороший декларативный формат макета и формат данных под него.

QAbstractTableModel

Нужен интерфейс с json.

SQL

Не нужен. Во-первых, разбираться с тонкостями работы драйвера удовольствие сомнительное. Во-вторых данные для отчёта не всегда табличные и не всегда их удобно приготовить в sql. В-третьих создание большого объёма документов упрётся в бд.

WYSIWYG

Не нужно

Нужно

Вот так это сделали js хипсторы: http://pdfmake.org/playground.html
Там плохо: смесь данных с макетом, время генерации, бедная документация. Но сама задумка годная.

Нужно

Обоснуй.
Написать

{
   table : {
       cols : 8, 
       widths : {"1-6" : "*", 7 : "10%", 8 : "20%" }
   }
}

Нужно, чтобы он брал json/xml/etc макета, «компилировал» его, потом брал json с данными (хоть через stdin/fifo) и быстро собирал pdf'ку. Цель - 5мс на pdf из 10 а4 с кучей таблиц и qr кодов

для такого есть xsltproc.

собственно весь «вкус» генераторов отчётов - быстро и ненапряжно делать __макет__, не изучая для этого json,xml,xsl и прочие тыщщи технологиий.

если-бы не Qt, я-бы даже такое (топик) взял на покрутить-повертеть :-)

для такого есть xsltproc

Для какого «такого»? Он pdf может выплёвывать с штрихкодами и qr-кодами? Пример в студию.

собственно весь «вкус» генераторов отчётов - быстро и ненапряжно делать __макет__

А потом долго и напряжено его выравнивать мышкой и вводить циферки в редактор свойств, чтобы он не выглядел как кусок дерьма.

то есть, у вас нет опыта работы с генераторами отчётов. При умении ими аользоваться описанный ввми ужас не грозит. Ыы ошибочно принимаете свой слишком маленький опыт за истину Я пользовался разными популярными - Oracle Reports, CrystalReports, Jasperreports, Pentaho Reporting. После освоения какого-нибудь из них очваивать другие легче.

Также делал отчёты чисто программным путём. Но объём программирования при этом обычно слишком большой, и я некоторые отчёты, которые первоначально сделал программно, потом переделал в генераторе отчётов для дальнейшего развития.

Обычное ограничение ненераторов отчётов - возможности форматирования в Еxcel. То есть, правильные размеры клеток задать можно. Но раскрывающийся иерахический диапазон строк или непрокручиваемы заголовок нельзя. Для этого нужна дополнителтная обработка отчёта в программе на предпочитаемом языке программирования (пользуюсь Java) или создание макросов в Excel.

Обсуждаемый в теме генератор отчётов мне испытывать лень. Их многоб Ну, ещё один появился.

Также делал отчёты чисто программным путём. Но объём программирования при этом обычно слишком большой

Так вот нужно, чтобы он не был слишком большой. Для этого и нужен хороший формат макета/формат данных.

у вас нет опыта работы с генераторами отчётов

И я даже не хочу иметь опыт создания отчётов сложнее чем табличка с суммой/подсуммой на этих ваших генераторах. Там всё, что ломает табличное представление превращается в блудные танцы с sql и встроенными в генератор костылями.

Все хорошо, только не понял,

под какую версию Qt ?
какая лицензия ?

Нет, там не всё открыто.

Начиная с Qt4.8 и выше. Лицензия LGLP

5мс на pdf

Откуда такое требование? У тебя сверхчеловеки каждые 5мс отчёты перечитывают?

Sql вкорячивать тоже не надо

Ещё как надо. Нужно иметь возможность плагином добавить любой источник данных.

json/xml/etc написать руками без гуя

Чтобы у тебя вместо юзеров шаблоны программисты делали?

Не нужно, разве что для мышевозов. Нужен хороший декларативный формат макета и формат данных под него

Дурак что ли. Это не дело рзработчика, а юзер не сможет в тексте всё разметить. Ему в идеале нужно иметь что-то похожее на эксель и пауэрпоинт.

создание большого объёма документов упрётся в бд

Уж во что, но точно не в бд.

Новость не подтвердили, или ты даже не пытался, сразу в форум закинул?

Так-то на мини-новость вполне бы потянуло, если оформить почётче.

На официальном сайте LimeReport написано что версия 1.5 вышла

Да и на github тоже

Откуда такое требование?

Надо генерить 300к платёжек каждый месяц и хранить их где-то. Еще кейс - массовая рассылка.

Ещё как надо. Нужно иметь возможность плагином добавить любой источник данных.

И причём тут sql? Json можно сделать из чего угодно, например, а для sql нужен интерфейс к твоей любимой субд.

Чтобы у тебя вместо юзеров шаблоны программисты делали?

Так программисты их по факту и делают для юзеров это слишком сложно, потому что нужен датасет как минимум. SQL тоже юзеры у тебя будут писать? Максимум, что юзеры могут - это OLAP, и то не все.

Начиная с Qt4.8 и выше.

Ух ты, годнота.

Лицензия LGLP

В смысле LGPL? Если да, то тоже годно. Вообще, я бы на сайте про опенсорс засовывал бы упоминание про лицензию в первое сообщение — тупых вопросов будет меньше.

Если надо по 5 запросов на платёжку на лицевой для 300к лицевых точно упрётся в бд. Запрос - 4 мс минимум, а по факту до 20-50. И это я сужу только по своей деревне.

Ему в идеале нужно иметь что-то похожее на эксель и пауэрпоинт.

Есть уже идеальный OLAP для такого, некоторые юзеры вполне справляются.

Так программисты их по факту и делают для юзеров это слишком сложно, потому что нужен датасет как минимум. SQL тоже юзеры у тебя будут писать? Максимум, что юзеры могут - это OLAP, и то не все.

Угу, помню, как мы купили Oracle Discoverer и сделали кучу отчётов на оном в надежде, что юзеры будут их править и создавать свои. В результате правили всё равно програмисты, а установка и поддержка этого добра на объектах был тот ещё секс, поэтому в следующих проектах плавно вернулись к отчётам жёсткой формы непосредственно из программ.

для sql нужен интерфейс к твоей любимой субд

И в чём проблема? Чтобы сдампить бд в json, тоже понадобится интерфейс.

SQL тоже юзеры у тебя будут писать?

У меня служба эксплуатации вполне умела в SQL, когда я этой хернёй занимался, но в целом не вижу проблемы в разделении труда. К тому же различные аналитики это уметь обязаны.

И при 300к платёжек я всё равно не вижу откуда ты взял 5мс.

И в чём проблема? Чтобы сдампить бд в json, тоже понадобится интерфейс.

Но это будет твой интерфейс, а не велосипед на qt, который не понятно, будет ли ехать. Плюс sql не нужен еще по двум причинам.

но в целом не вижу проблемы

О том и разговор.

И при 300к платёжек я всё равно не вижу откуда ты взял 5мс.

Оттуда, чтобы не ждать сутками, когда они все доделаются. Одна либа на js делает их за 30мс/pdf, сейчас на jasperreport мы делаем примерно за секунду на одном ядре и занимает это около суток. Было бы нормальное приложение делалось бы всё меньше чем за 10 минут.
5 мс взял из того расчёта, что кривая либа на js с кучей зависимостей может работать минимум раза в 2 быстрее, а весь js код в 3 раза медленнее, чем плюсовой. Как-то так.

О том и разговор

Я именно про разделение. Юзер запилил шаблон, перечислил нужный набор полей, оставил заявку на написание запроса. Ты потом пишешь только запрос, или не ты, а кто угодно, кому не нужно уметь в шаблоны, а только знать структуру БД и уметь в запросы.

Дошло. Оно за раз всё напечатать должно.

Но всё равно же данные надо предварительно из бд извлечь, а потом ещё и напечатать это всё.

Но всё равно же данные надо предварительно из бд извлечь, а потом ещё и напечатать это всё.

Не, печатать не надо, всё складывается на диск, что-то рассылается, что-то отправляется.
Прикол в том, что один большой запрос сильно быстрее чем 1.5М мелких.

Юзер запилил шаблон, перечислил нужный набор полей, оставил заявку на написание запроса. Ты потом пишешь только запрос, или не ты, а кто угодно, кому не нужно уметь в шаблоны, а только знать структуру БД и уметь в запросы.

Мы так неделю заявки будем друг другу носить, да и не умеет никто делать шаблоны. Максимум - олап и то не для всех.

Да. Хорошо так помечтать, что юзеры что-то там будут делать, по факту да, олап - сложна, шаблоны кривые и едут, в итоге все делает какой-то программист, а программисту зачем нужен гуй. Это всё олап оно для аналитиков может быть и интересно, но юзеру надо нажать копну и чтобы напечаталось, говорил наш начальник.

Ты потом пишешь только запрос

Сложность еще в том, что не все отчёты бывают строго табличные. Есть, например начисление по нормативу и сверх норматива. В таблице идут отдельными записями, а в отчёте должны быть в столбцах рядом. Какое решение? Делать на sql? Получится говнище на вложенках. Делать в отчётах? Говнище на отчётных костылях. Я и не говорю про то, как юзеры будут это осиливать, потому что тут напрашивается перебор датасета, а это уже программирование.

Я делал функциональную разметку XLSX. Причём не строго табличную не смотря на XLSX. Было много визга, но после того как техпис запилила туториал с примерами в дополнение к документации, визги резко утихли.

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

XLSX нам не нужен. Нужен именно pdf, чтобы никто ничего не правил руками в готовом документе. Ну и ключевое тут

Я делал

Я тоже могу сделать хоть гопака в pdf на этой своей ноде. Причём только тут генераторы отчётов.

Когда-нибудь свалю. Надо доделать все дела, чтобы было чем выделываться перед hr'ами.

Да не суть что именно вам нужно, мне нужен был xlsx, но я тебе не про это, а про подход. XLSX на это вообще плохо ложится. А сабж — это ровно то, что нужно.

Так а какая разница? Всё равно программист делает функциональный шаблон. А если уж шаблон функциональный, то и нужна для этого какая-то хрень, чтобы такие шаблоны лепить. Чтобы там хоть в строчку, хоть в столбик, хоть в лесенку. Как по мне на js такое слепится нормально. Запилил структуру, всунул в неё функций взял тестовые данные, собрал, проверил. Собрал json из sql выхлопа - готово. И пляши хоть как никто тебя не ограничивает, главный минус - либы не сильно шустрые и делают хрен пойми что.

А вусивуги не знаю зачем нужны, там тебя сразу ограничивают функционалом гуя, а задачи бывают очень разные и странные.

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

Всё равно программист делает функциональный шаблон

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

Как по мне на js такое слепится нормально

Ты про то, чтобы захардкодить? Тоже подход, но при наличии хоть какого-то шаблонизатора, всё равно будет проще.

В твоём случае не вижу проблем юзать html. Удобно же и экспорт в pdf без проблем можно делать, хз только про скорость.