OdsReport - прямой вывод в файл OpenOffice.org Calc

[mdimich]

Представляю на суд общественности написанную мною компоненту — TOdsReport для Lazarus.
OdsReport позволяет формировать отчеты в формат OpenOffice.org Calc минуя COM. Вывод ведется напрямую в файл. Для генерации отчета нужен один или несколько источников данных (DataSet), содержащих данные, а также предварительно подготовленный шаблон с уже готовой разметкой и форматированием. Шаблон оформляется следуя несложным правилам: ##DATASET.FIELDNAME## - в шаблоне заменяется на значение поля «FIELDNAME» из источника данных «DATASET» (например TSQLQuery). Данные выводятся порциями, определенными «Диапазонами данных» _DATASETTOSCROLL_, причем возможно неограниченное вложение диапазонов, что позволяет делать многоуровневые отчеты с подзапросами из нескольких источников данных. Доступно использование формул, но с некоторыми ограничениями: допускаются вычисления сверху вниз, т.е. в формуле нельзя использовать ячейки, расположенные ниже на листе, если на данном этапе еще неизвестно их расположение.
Не поддерживаются прочие встроенные объекты — диаграммы, рисунки и т.п. Типы данных пока тоже ограничены (число, строка, дата). В остальном, почти все работает и показывает впечатляющую производительность по сравнению с COM.
Как упоминалось, зависимости минимальны: требуется только zip/unzip для работы. Установленный OpenOffice не нужен. В настоящее время проект у меня уже реально используется под внутренним web-сервером: юзер клацает на кнопку в браузере, сформированный файл отсылается ему на почту или предлагается ссылка для скачивания.

Но стоит заметить, что релиз исключительно тестовый! Для работы мало годится. Я его оформил в компонент, написал лист документации, сделал наброски рабочей тестовой программки, чтобы вы оценили, и вынесли вердикт, в каком направлении мне его развивать? И нужно ли это вообще???
Вариант 1: пишу все исключительно для себя (потому как мне нужно), адаптированно для себя родного, и соответственно ни с кем не делюсь разработками, ни перед кем не стыдно за исходники, никому ничего не должен.
Вариант 2: Если кого-либо заинтересует проект, поступит критика и предложения, то проект продолжит публичную жизнь: буду делать багфиксы, оптимизирую код (ой как мне сейчас за него стыдно, но хотелось быстрее получить рабочий прототип), добавлю новые фичи, функциональность и т.п.

[Vadim]

Вот такая вот ошибка выскакивает при попытке сформировать отчёт:

Вот шаблон:

В качестве источника данных используется база MySQL и компоненты ZEOS 6.6.4 (TZReadOnlyQuery).
OpenOffice 3.0.1

[mdimich]

Vadim, действительно, мой недочет. Спасибо за багрепорт. Необрабатывался тип данных - LargeInt (судя по скринам, он у тебя использовался для поля traffic). Первыми пунктами в "to do" так и запишем, пересмотреть типы данных.

В версии 0.0.5 ошибка исправлена, перезалил на форум. Если еще не охладел к экспериментам, попробуй опять? Буду очень признателен! Тестер ты просто замечательный (или это я такой невнимательный ) !

[Vadim]

Ок. Сейчас попробую...

Добавлено спустя 5 минут 24 секунды:
Что-то у меня тот же самый файл скачался. На всякий случай переустановил, но та же ошибка.

Добавлено спустя 30 минут 54 секунды:

Принудительно перекомпилировал файл ooda.pas - теперь работает. Однако не так, как я ожидал - выдаётся всего одна строка, а чтобы весь DataSet выдавался, нужно что-то специально указывать?

[v-t-l]

зависимости минимальны: требуется только zip/unzip для работы.

если сохранять в формате .fods, то не потребуется zip/unzip. Правда, для открытия/сохранения такого документа OpenOffice требует установленный JRE.

[Vadim]

Можно какой-нибудь zip-юнит присобачить, тогда внешний zip\unzip не потребуется.

[mdimich]

Однако не так, как я ожидал - выдаётся всего одна строка, а чтобы весь DataSet выдавался, нужно что-то специально указывать?

Необходимо определить диапазон данных. Делается это через меню OOO Calc: Данные --> Определить диапазон данных.

Т.е. если ты хочешь выводить данные из датасета q1, то нужно объявить диапазон данных в OOO Calc с именем _Q1_, в диапазон должна попадать строка 3, где ссылочки ##q1.host## и ##q1.traffic##
Имя диапазона _Q1_ означает, что при выводе, датасет Q1 будет скроллироваться. Именно это тебе нужно.

Я про это мельком написал, но снимаю шляпу - непонятно. Надо будет туториал с картинками сделать.

А насчет встроенного zip/unzip - это наверное дело, хотя не unix-way. Но можно ведь сделать опционально. Если есть предложения - будем реализовывать.

.fods? попробуем посмотреть в эту сторону. В любом случае если функционал наращивать, работающие моменты ломать не буду.

Спасибо, я рад вашей активности!

Как задать диапазон данных

[Vadim]

mdimich
Ага, теперь понятно. Мне отчего то показалось, что диапазон даных надо прямо в компоненте вводить.

Добавлено спустя 9 минут 38 секунд:

А насчет встроенного zip/unzip - это наверное дело, хотя не unix-way.

Зато windows-way. Дело в том, что давно уже прошли те времена, когда pkzip\pkunzip (или WinZip ) в обязательном порядке стоял на каждом компьютере. На сегодня стандарт - это WinRAR. Однако как раз тут и зарыта большая и вредная собака - в большинстве случаев WinRAR этот нелицензионный. Надеятся, что все в срочном порядке поставят 7-zip пока что наивно . Поэтому встроенный zip\unzip крайне необходим именно для пользователей Windows. Можно сделать условную компиляцию - если Linux, то системный zip\unzip работает, т.к. вроде как почти во всех дистрибутивах они устанавливаются по умолчанию, а если Windows, то работает встроенный zip-модуль.

[mdimich]

Можно сделать условную компиляцию - если Linux, то системный zip\unzip работает, т.к. вроде как почти во всех дистрибутивах они устанавливаются по умолчанию, а если Windows, то работает встроенный zip-модуль.

Да, ты прав. Так и сделаю.

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

И я так понял, Vadim, что у тебя заработало? Спасибо тебе!

[Vadim]

mdimich
Это тебе спасибо! Ты затеял черезвычайно хорошее дело.

Добавлено спустя 16 часов 59 минут 6 секунд:
mdimich
Слушай, а вот если у меня числа в DataSet'е типа 222,22 то в отчёт попадают цифры типа 22222, т.е. как целое число.


И ещё, если указатель курсора стоит на последней строке DataSet'а, то в отчёт вообще никакие цифры не попадают.

[mdimich]

Насчет дробных знаков - примени к ячейке соответствующий формат в шаблоне, как число с необходимым кол-вом дробных знаков;

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

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

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

...............
упс, сразу не разглядел. действительно бяка с дробными числами. можешь на почту или сюда кинуть твой шаблон и результирующий файл, как только он будет сформирован, без предварительных открытий/сохранений, чтобы OOO туда никакие коррективы не внес. Потому как я сейчас на oracle такое проверил - все красиво, на firebird'e через TSQLQuery потерялись дробные знаки (хотя в грид тоже без дробных знаков выводится )

[Vadim]

Я несколько числовых шаблонов проверил - везде дробная часть отсекается.
Вот шаблон и сформированный файл: http://212.41.1.157/img/err/reports.zip

Добавлено спустя 16 минут 14 секунд:
У DataSet'а можно проверять RecordCount и если он равен нулю, то ничего не делать. А вот по поводу позиционирования записи, можно поставить закладку (Bookmark), потом перейти на первую запись, вывалить DataSet в отчёт и вернуться на закладку.

[mdimich]

Я несколько числовых шаблонов проверил - везде дробная часть отсекается.

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

У DataSet'а можно проверять RecordCount и если он равен нулю, то ничего не делать.

Там все несколько хитрее реализовано... Как бы объяснить...
Отчет выводится сверху вниз. Что выведено, то выведено. А вот если есть формула внизу, которая ссылается на ячейки, которые не вывелись, потому как в датасете небыло данных? Какая ситуация была с эти датасетом, я не запоминаю - на сложных отчетах получится большой расход памяти. А OdsReport позиционируется как быстрый и экономный. Вот сейчас получается, что ячейки, под вывод датасета получатся пустыми, а формула - нерабочая. Невыводить строку с формулой тупо нельзя, я думаю. Вижу как вариант, формулу, а точнее всю строку с формулой объявлять зависимостью от датасета. Это решит данную проблему и сделает отчет более гибким, не особо усложнив структуру. Позже попробую так сделать.

А вот по поводу позиционирования записи, можно поставить закладку (Bookmark), потом перейти на первую запись, вывалить DataSet в отчёт и вернуться на закладку.

Будут, букмарки. Уже вставляю....

Добавлено спустя 8 часов 23 минуты 11 секунд:
Обновились до 0.0.6. Исправлено несколько известных ошибок, добавлено несколько новых, неизвестные не тронуты
Итак:
- добавлен метод AutoClose(); - по завершении работы закрывает все активные датасеты датасеты, указанные в диапазонах данных;
- исправлена ошибка, приводящая к неработоспособности итогового файла при наличии в наборе данных символов &<>"
- исправлена ошибка, приводящая к искажению дробных чисел при различных установках региональных настроек (спасибо Vadim).
- при установленном свойстве AutoOpen = true, датасеты теперь не только автоматически открываются, если были закрыты, но и позиционируются на 1-ю запись в наборе данных (по предложению Vadim (мне же бывает необходимо, чтобы так не происходило));
- введены закладки (bookmark). За поддержку закладок отвечает директива условной компиляции {$DEFINE bookmarks} - по умолчанию уже включена (см. ooda.pas). Тут есть неприяная особенность, которая мне не понравилась, и требует отказа от закладок или исправления поведения:
Dataset.BookmarkValid () всегда возвращает false. Почему, так и не понял, надо разбираться. Однако, если работа идет с одним набором данных, то все работает отлично. Если сделать второй набор данных, и объединить их как Master-Detail, то при попытке перехода на закладку второго датасета имеем риск получить AccessViolation. Чтобы этого избежать, добавил проверку if BookmarkValid (), которая впринципе должна за это отвечать. Однако, как упоминал, всегда получаю false, даже если dataset не переоткрывать ниразу.
Так что тут думать надо, как сделать. Половинчатое решение мне не нравится. Либо все датасеты контролируются закладками, либо ниодного. Вы как думаете? Кроме того связки Master-Detail для меня очень критичны, т.к. постоянно ими пользуюсь, а OdsReports их достаточно хорошо поддерживает, да и создавался он для этого.
- предполагается в будущих версиях измененить именование диапазонов данных. Рекомендуется диапазоны данных именовать без символов подчеркивания, аналогично имени соответствующего датасета в программе. В следующих релизах символы подчеркивания будут исключены, и зарезервированы под другие нужды (предполагаю сделать мнимые, или фиктивные диапазоны данных, которые будут определять реакцию того или иного блока отчета на состояние датасета. Т.е. если recordcount = 0, то и шапку, и итоги внизу не выводить, если они попадают в такой диапазон). Такое именование мне кажется более логичным. В текущей версии можно использовать имена как "_Query_" так и "Query". Если отговорите, то останется как и было.

В общем. пока все. На очереди как всегда багфиксы, букмарки и обещанный встроенный zip/unzip - просто пока не дошли руки до него.

[Vadim]

mdimich
По поводу Букмарков.
В принципе от их использования можно отказаться и использовать старый проверенный метод, который я применял ещё на заре программирования (по совету Владимира Ильича Ленина ):
1. Запоминаем текущий номер записи DataSet'а:
CurrentRecord:=TDataSet.RecNo;
2. После выгрузки данных из DataSet'а в отчёт, переходим на первую запись и относительно неё передвигаемся на тот номер записи, который запомнили:
TDataSet.First;
TDataSet.MoveBy(CurrentRecord);

P.S. Этот метод не будет работать с DataSet'ами типа Unidirectional, поэтому прежде чем его применять, нужно сначала это проверить:
If not TDataSet.IsUniDirectional Then
//Применяем переход по номеру записи
Else
//Обламываемся...

Утешает единственное обстоятельство, что IsUniDirectional по умолчанию установлено в False, т.е. если не предпринимать специальных мер, то мы работаем с нормальным буферизированным DataSet'ом, по которому можно передвигаться взад и вперёд куда вздумается.

Добавлено спустя 11 минут 36 секунд:
Впрочем, с Unidirectional букмарки тоже работать не будут.

[mdimich]

Об этом я уже подумал..
Есть подводные камни, связанные с detail-датасетом: Detail датасет может переоткрываться много раз, по мере скролла master'а. Если использовать RecNo, где гарантия, что запись, на которую нужно спозиционироваться будет с тем же номером в выборке (другой порядок сортировки, да и запрос sql может быть динамически изменен)? Использовать locate, по значению - тоже не факт, что будет уникальность?
Считаю, что это можно оставить на совесть логики основной программы, или восстанавливать Master-датасеты, но не detail. Как думаете?