LINUX.ORG.RU

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

 , , , ,


0

2

1. Многостраничность

2. Диалоги

3. Добавлены светлая и темная тема в дизайнере отчетов.

4. Инициализационный скрипт

5. Уменьшено потребление памяти

6. Переработан объект управления источниками данных

7. Добавлено контекстное меню у элементов отчета

8. Добавлена возможность использовать QJSEngine вместо устаревшего QtScript.

9. Улучшен визуальный дизайнер отчетов.

10. Добавлена поддержка дюймов.

11. Добавлен встроенный редактор диалогов.

12. Улучшен редактор скриптов.

13. Добавлена возможность сборки библиотеки без встроенного визуального редактора отчетов.

14. Добавлена возможность создавать многоязычные отчеты.

15. Добавлена возможность обработки событий времени генерации отчета посредством скриптов.

16. Добавлена возможность создания оглавления отчета.

17. Добавлена вертикальная группировка.

18. Добавлена возможность передавать изображение в отчет через переменную отчета.

19. Добавлена возможность печати на рулоне.

20. Добавлена печать одной страницы отчета на нескольких листах бумаги.

21. Добавлена возможность печати на нескольких принтерах.

22. Добавлен компонент для отображения графиков.

23. Добавлена возможность использовать групповые функции в заголовках.

24. Добавлена возможность создавать промежуточные итоги в нижнем колонтитуле страницы.

25. Улучшен режим редактирования результатов генерации отчетов.

26. ... много других небольших улучшений и исправлений ошибок.

Официальный сайт: http://www.limereport.ru Ссылка для скачивания: https://github.com/fralx/LimeReport либо https://sourceforge.net/projects/limereport/

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



Последнее исправление: ikon (всего исправлений: 1)

Нужно, чтобы он брал 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 отчёта в час до принтера

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от crutch_master

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

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

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

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

MKuznetsov ★★★★★
()
Ответ на: комментарий от MKuznetsov

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

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

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от MKuznetsov

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

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

crutch_master ★★★★★
()
Ответ на: комментарий от crutch_master

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

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

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

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

Partisan ★★★★★
()
Ответ на: комментарий от Partisan

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

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

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

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

crutch_master ★★★★★
()
Ответ на: комментарий от crutch_master

5мс на pdf

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

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

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

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

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

WitcherGeralt ★★
()
Ответ на: комментарий от WitcherGeralt

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

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

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

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

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

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

crutch_master ★★★★★
()
Ответ на: комментарий от crutch_master

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

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

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от crutch_master

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

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

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

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

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

WitcherGeralt ★★
()
Последнее исправление: WitcherGeralt (всего исправлений: 1)
Ответ на: комментарий от WitcherGeralt

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

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

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

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

crutch_master ★★★★★
()
Ответ на: комментарий от WitcherGeralt

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

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

crutch_master ★★★★★
()
Ответ на: комментарий от crutch_master

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

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

WitcherGeralt ★★
()
Ответ на: комментарий от crutch_master

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

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

WitcherGeralt ★★
()
Ответ на: комментарий от WitcherGeralt

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

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

crutch_master ★★★★★
()
Ответ на: комментарий от WitcherGeralt

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

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

crutch_master ★★★★★
()
Ответ на: комментарий от hobbit

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

crutch_master ★★★★★
()
Ответ на: комментарий от WitcherGeralt

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

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

crutch_master ★★★★★
()
Ответ на: комментарий от crutch_master

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

WitcherGeralt ★★
()
Последнее исправление: WitcherGeralt (всего исправлений: 1)
Ответ на: комментарий от crutch_master

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

WitcherGeralt ★★
()
Ответ на: комментарий от WitcherGeralt

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

Я делал

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

crutch_master ★★★★★
()
Ответ на: комментарий от crutch_master

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

WitcherGeralt ★★
()
Ответ на: комментарий от WitcherGeralt

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

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

crutch_master ★★★★★
()
Ответ на: комментарий от crutch_master

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

WitcherGeralt ★★
()
Ответ на: комментарий от crutch_master

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

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

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

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

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

WitcherGeralt ★★
()
Ответ на: комментарий от crutch_master

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

WitcherGeralt ★★
()
Последнее исправление: WitcherGeralt (всего исправлений: 1)
Ответ на: комментарий от WitcherGeralt

Слишком не усердствуй над доделыванием

Эта задача пока не встаёт. По крайней мере, пока опять что-нибудь не накосячат с jasper report'ом.

crutch_master ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.