Модуль печати

[Vladimir]

Модуль печати предлагаю делать с использованием OpenOffice
(LibreOffice). Шаблон создается в ОО. Модуль печати открывает шаблон и
заполняет его актуальными данными. Использование OpenOffice, а не
самописного конструктора отчетов позволит быстро создать инструмент
печати, который может экспортировать отчет в различные форматы,
которые поддерживает ОО.

[Drake]

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

[Vladimir]

Не думаю, что это проблема. OpenOffice или LibreOffice бесплатны. Я не
знаю NC-report. Позволяет ли он экспортировать отчет в различные
форматы? Давай просто обсудим тогда интерфейс модуля печати, а ближе к
делу будет видно, на чем его реализовать.

[Vladimir]

Предлагаю данные для печати передавать интерфейсу в виде QMap<QString,
QVariant>, где QString - название поля, например "Шапка1", "Таблица:
Артикул" и т.п., а QVariant - значение. Ядро заряжает этот QMap и
передает его для печати. Модуль печати просматривает шаблон, находит
поля для печати и заполняет их значениями из QMap. Вся разметка,
шрифты, курсивы, линии и т.п. уже должны быть заданы в шаблоне.

[Drake]

А для сложных отчетов нерегулярной струтктуры? А для группировок? А
для подытогов и картинок?
XML.

[Drake]

Впрочем, это я что-то погорячился, прошу прощения.
На, наиболее удобным способом передачи данных в отчет будет мэп.
Единственно, я бы не привязывался именно к "полю", и настоял на
семантическом значении QMap<Имя параметра, Значение параметра>, т.к.,
как уже было замечено,не все отчеты имеют регулярную табличную
структуру.
То есть, получим нечно вроде
TReport* TReportEngine::prepareReport(const TReportTemplate&, const
TReportContext&)

и

bool TPrinter::print(const TReport*)

Где

TReport - заполненный отчет
TReportTemplate - шаблоно тчета
TReportContext - контекст отчета (тот самый мэп)

TPrinter - печать

[villager]

печать - самая важная часть системы
с нее вообще начинать надо:

решить задачу вывода на печать (PDF, XLS ...)
ттн с запросом номера

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

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

[Drake]

Экспорт в разные форматы делается средствами кьюта. И обсуждается
сейчас не он.
Вывод на печать? Делается средствами кьюта, либо внешним приложением,
аля ОпенОфис, либо NCReport. И, к слову сказать, обсуждается сейчас не
он.
Внешние ключи, параметры? Это обычные составные элементы SQL-запроса.
Дада, обсуждаются не они.

Вопрос в интерфейсе и API модуля печати. Существующие инструменты
позволяют решить все прочие задачи.

Ни с отчетами ни с печатью особых проблем я не предвижу. ВОт если мы
ВНЕЗАПНО рещим делать построитель отчетов - проблемы могут возникнуть.
Но, надеюсь, делать его мы не будет.

[Vladimir]

Да, думаю, что нам не нужен пока никакой построитель отчетов. В нем
можно недолго завязнуть. Сейчас нам нужно максимально простое и
эффективное решение. И предлагаю для упрощения пока принять допущение,
что все отчеты состоят (а для большинства отчетов так и есть) из
шапки, табличной части и подвала. Я представляю себе, что это будет
примерно так: если отчет создается заново, то программа берет
заготовку отчета (пустой файл OpenOffice, который как мы помним
является файлом XML), заполняет его всеми шаблонами переменных
(создает шаблон документа общего вида) и открывает пользователю.
Шаблон переменной (не знаю, как правильно это назвать) - это просто
название переменной вида "[<[пусто]|Таблица>:<Справочник|
Документ>.<Имя_поля>]", а не ее значение. Например: "[Документ.Дата]",
"[Константы.Руководитель]", "[Таблица:Номенклатура.Имя]",
"[Таблица:p1.Кол]" и т.д. Шаблоны переменных отличаются от обычных
полей таблицы наличием квадратных скобок (например). Пользователь
расставляет шаблоны переменных так, чтобы эта заготовка приобрела вид
документа и сохраняет шаблон. Далее при создании отчета программа
берет этот шаблон и заполняет его реальными данными из QMap. QMap
содержит все значения, которые потенциально могут попасть в отчет, но
не все они попадают в него, а только те, которые есть в шаблоне
документа. Мне кажется, что в таком случае можно обойтись и без
скриптов.

[Александр Руденко]

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

Ок, у меня вырисовывается следующее:

TReportTemplate

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

что-то вроде

<Report>

  <Header>

    <Item>[Отчет1.Заголовок1]</Item>

    <Item>[Отчет1.Заголовок2]</Item>

    <Item>[Приложение.ДатаПодачиОтчетай]</Item>

  </Header>

  <Body>

     <Item><Отношение1.Атрибут1></Item>

     <Item><Отношение1.Атрибут2></Item>

     <Item><Отчет1.Дата подачи></Item>

  </Body>

  <Footer>

  </Footer>

</Report>

TReportContext:

Заполнили мап с именами переменных и их значениями.

Также, указали, в каком формате его хотим - OpenOffice, CSV или что еще.

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

Возникает вопрос по переменным - как распознать, когда переменная - это единичное значение,а когда - множество значений? Можно оставить это на семантику, то есть [] скобки для единичных значений, а <> скобки - для множеств. Можно научить движок понимать, что вот такая-то переменная - это множество, и их можно обрабатывать по-разному.

Мне больше импонирует второй вариант.

[Vladimir]

Думаю, что тут будет все просто. В шаблоне строка таблицы будет в
единственном числе и будет содержать значения, например:
[таблица:номенклатура.имя], [таблица:номенклатура.едизм],
[таблица:p1.кол], [таблица:p1.цена], [таблица:p1.сумма]. В QMap данные
для заполнения будут выглядеть так:
"таблица1:номенклатура.имя", "стартер 2101"
"таблица1:номенклатура.едизм", "шт"
"таблица1:p1.кол", 2
"таблица1:p1.цена", 1800
"таблица1:p1.сумма", 3600
"таблица2:номенклатура.имя", "тосол (5л)"
"таблица2:номенклатура.едизм", "шт"
"таблица2:p1.кол", 10
"таблица2:p1.цена", 250
"таблица2:p1.сумма", 2500
Т.е. модуль печати смотрит шаблон, и если нашел шаблон "таблица", то
добавляет новые строки и подставляет последовательно из QMap значения
"таблица<n>", где n - номер строки.

[Александр Руденко]

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

Дальше - сравним, и обусудим.

[villager]

Согласен, построитель отчетов вещь сложноватая
я потратил полгода примерно, и это на питоне

есть еще проще вариант с шаблонами
прога reportf
шаблон хранится в RTF, с разметкой секций и тегами переменных
данные - в текстовом файле в виде тег:данные

можно оттуда взять идею

[Александр Руденко]

Мы пока больше идею обсуждаем. Что до формата - мне больше по душе XML для шаблонов.

[trdm]

Блин, написал тут мессадж, "ответить автору" но я его не вижу ((
А он может быть полезным.

[trdm]

On 18 сен, 11:35, Александр Руденко <drake.l...@gmail.com> wrote:
> Скрипты - это всего лишь один из способов управления потоком данных, так
> что, на мой взгляд, будет даже лучше сначала обойтись без них, и навесить
> позднее.

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

А вот и "демонстрация"

> Возникает вопрос по переменным - как распознать, когда переменная - это
> единичное значение,а когда - множество значений? Можно оставить это на
> семантику, то есть [] скобки для единичных значений, а <> скобки - для
> множеств. Можно научить движок понимать, что вот такая-то переменная - это
> множество, и их можно обрабатывать по-разному.
> Мне больше импонирует второй вариант.

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

Построитель в моем сообщении следует понимать как объект-манипулятор,
который работает со след. вещами: простой шаблон, результат и
переменные вовремя ему скармливаемые.
например.
есть некий шаблон
<report name = "Накладная">
<section name = "Шапка">
<table>
<tr><td>Накладная No. <temlp>НомерДока</temlp> от <temlp>ДатаДока</
temlp></td></tr>
<tr><td>Поставщик <temlp>Поставщик</temlp> ; договор No.
<temlp>договорНомер</temlp> от <temlp>ДоговорДата</temlp></td></tr>
</table>
</section>
<section name = "ШапкаСтрок">
<table>
<tr><td>No. ПП </td><td>Товар </td> <td>Кол-во</td><td>Цена </
td><td>Сумма</td></tr>
</section>

<section name = "Строка">
<tr><td><temlp>НомерПП</temlp></td><td><temlp>Товар</temlp> </td>
<td><temlp>Колво</temlp></td><td><temlp>Цена</temlp></
td><td><temlp>Сумма</temlp></td></tr>

<section name = "ШапкаСтрокКон">
<table>
</section>
</report>

Абстрактный скрипт:
КО = новый КомпоновщикОтчета;
КО.ИсходныйШаблон(...);
КО.УстановитьПараметр("НомерДока",120);
КО.УстановитьПараметр("ДатаДока",01.12.2011);
КО.УстановитьПараметр("Поставщик","Дятлов ИП");
КО.УстановитьПараметр("договорНомер","----");
КО.УстановитьПараметр("ДоговорДата","----");
КО.ВывестиСекцию("Шапка"); // << компоновщик знает какая секция и
может "достать" переменные ему переданные и поменять в <temlp>Товар</
temlp> "Товар" на его значение.
КО.ВывестиСекцию("ШапкаСтрок");
НомерПП = 0;
Пока Запрос.Следующий() Цикл
НомерПП = НомерПП + 1;
КО.УстановитьПараметр("НомерПП",НомерПП);
КО.УстановитьПараметр("Товар",Товар);
КО.УстановитьПараметр("Колво",Колво);
КО.УстановитьПараметр("Цена",Цена);
КО.УстановитьПараметр("Сумма",Сумма);
КО.ВывестиСекцию("Строка");
КонецЦикла;
КО.ВывестиСекцию("ШапкаСтрокКон");
КО.ПоказатьОкноОтчета();
-------------------------------------------------------------------
А теперь попробуйте придумать кнопочно галочный механизм которые это
реализует.
Поверьте, один хорошо сконструированный компоновщик + пара запросов
сможет убрать много гемороя.

[villager]

tdrm +1,
reportf примерно так и устроен внутри
только вместо html-шаблона - RTF, что приятнее - рисовать документ
можно в Word
а вся логика - в скрипте создающем текстовый файл

так что без скриптов не обойтись

[Александр Руденко]

>>В случае 2 вам прийдется писать парсер, уходя "влево от задачи".

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

>>Вам нужен нормальный "построитель" выполняющий вывод простейшими командами.

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

>>Да и в случае такого как у вас подхода вам прийдется много времени убить на макетирование "специального" шаблона. Тогда как из скрипта это можно сделать гибче.

Какого специального шаблона? Много - это сколько? Сделать рабочий набросок подобной системы можно за 3-4 дня. Просто шаблон с переменными, и просто набор значений переменных, а из всего этого движок сформирует готовый отчет.

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

>>Поверьте, не существует идеального решения кроме скрипта и скуль-запроса и построителя.

Серебряной пули вообще не существует. В то же время, существуют FR, NC, Rave и Jasper. Можно воспринять, как материал для размышления.

Ты привел пример скрипта. Замечательно.

Рассмотрим, что делает скрипт.

Он:

1. Создает компоновщик. Я так понимаю - движок.

2. Задаёт движку шаблон.

3. Заполняет параметры.

4. Заполняет поля в цикле.

5. Выдаёт отчет.

О чем говорим мы:

1. Берется шаблон отчета.

2. Берутся значения переменных.

3. Передаются в движок.

4. Движок заполняет поля.

5. Выдаёт отчет.

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

Поясню свою позицию.

Есть шаблон отчета. Шаблон отчета - объект системы, им можно манипулировать как в исходном коде, как и в скриптах.

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

Есть движок, которому передаётся шаблон и контекст, и он выдаёт отчет.

Каждым из трёх объектов можно манипулировать из скрипта. То есть, это будет выглядеть примерно так (псевдокод):

TReportTemplate template("Ежемесячный отчет");//возьмем стандартный шаблон

template.addSection(TReportSection("Новая секция, которой раньше не было"));//изменим его, если нужно

TReportContext context;

context.setParameter("НомерДока",120);

context.setParameter("ДатаДока",01.12.2011);

context.setParameter("Поставщик","Дятлов ИП");
context.setParameter("договорНомер","----");
context.setParameter("ДоговорДата","----");
context.addSource(ListOfValues);

TReport report = TReportEngine::process(template, context);

delete template;

delete context;

report.show();

Понятное дело, это псевдокод, но идея именно в этом - по максимуму спрятать внутренний механизм заполнения отчета. Аля кьют.

[Vladimir]

Посмотрите файл https://docs.google.com/leaf?id=0ByTsPnuzNr-BYTg0Nzc0ODYtNDliMi00MzQ0LTllNGEtYTI2ZDllMWQ4NWJl&hl=ru.
Это шаблон накладной, созданный в OpenOffice. С помощью OpenOffice я
могу изменять внешний вид шаблона как хочу. Чем не кнопочно-галочный
механизм создания шаблона? Далее. Открываем этот шаблон как XML
(разворачиваем ods файл zip'ом и открываем файл content.xml). Находим
в нем этот кусок: https://docs.google.com/leaf?id=0ByTsPnuzNr-BYjgxMGM4OWYtN2QyNS00YzEyLTk3NmItNDVmYjFkYTM2MTY2&hl=ru
(см. с помощью FireFox например). Что мешает найти все значения в
квадратных скобках и заменить их на данные из QMap, про который я
говорил выше? Узел, где встречаются значения [таблица:...] размножим и
подставим значения из QMap<"[таблица<n>:...]">. Затем это сохранить,
запаковать обратно и открыть в OpenOffice. Вот и все, что должен
делать модуль печати... Далее пользователь из OpenOffice может
документ распечатать, сохранить в куче форматов, отправить электронной
почтой и т.д... Ядро передает модулю печати все данные, которые
открыты в текущей модели данных (документа, справочника или отчета)
плюс некоторые дополнительные, например. значения констант, т.е.
отпечатается то, что видно в данный момент на экране в текущей форме.
Если открыт документ, то отпечатается он, если открыт справочник, то
справочник (точнее результат выборки из справочника) и т.д. Таким
образом нам не нужен SQL запрос к базе.

[villager]

Vladimir, с шаблоном все ок
одно замечание
для определения детальной(привязанной к запросу) секции
надо ввести доп теги
типа:
[таблица:имя_таблицы]
а тут уже строка
[/таблица:имя_таблицы]

при сборке отчета компоновщик (ядро,движок) организует цикл по строкам
таблицы (запроса)
внутри же вложить теги подзаголовков/подитогов

[villager]

при обработке тега [таблица:] можно сразу организовать подсчет
подитогов

у меня в генераторе примерно так и сделано

[Александр Руденко]

Вернее, SQL запрос нужен, но, в идеале, никто не будет знать, где и как он выполнился. Да, идея неплохая.

Но мне, все-таки, нравится более просто подход и более простой отчет.

XML-ка с парой тэгов, и контекст, он же - мэп со значениями.

На выходе - что угодно, втч и документ для OO.

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

[Vladimir]

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

[Александр Руденко]

Финтифшлюшки придётся писать, да.

В общем, начнем с ОО, там дальше видно будет.

[trdm]

On 19 сен, 12:49, Vladimir <MorozovVladi...@mail.ru> wrote:
> Таким образом нам не нужен SQL запрос к базе.

Выборка из БД в любом случае делается - либо вами либо компоновщиком.
Данные не из воздуха появляются.
Плюс OpenOffice - кривое поделие, и дополнительный депенд.
Я как разработчик и внедренец решительно не приветствую лишние
заплчасти которыми к тому-же рулить надо с помощью лома.

[trdm]

On 19 сен, 13:50, Александр Руденко <drake.l...@gmail.com> wrote:
> Финтифшлюшки придётся писать, да.
> В общем, начнем с ОО, там дальше видно будет.

хто как, а я продолжу заниматься: http://code.google.com/p/unnstudioreport/
посмотрим, кто быстрее выдохнется от "пустых ударов в ненужную цель".

[Vladimir]

> Выборка из БД в любом случае делается - либо вами либо компоновщиком.
> Данные не из воздуха появляются.

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

> Плюс OpenOffice - кривое поделие, и дополнительный депенд.
> Я как разработчик и внедренец решительно не приветствую лишние
> заплчасти которыми к тому-же рулить надо с помощью лома.

Насчет кривости OpenOffice не согласен. У меня уже несколько лет нет
MicrosoftOffice, работаю только на OO, проблем в связи с этим не
испытываю. К тому же никто не мешает сделать другие варианты, если
нужно будет.

[Александр Руденко]

Да кривой он, кривой, никуда от этого не деться, и тормозной вдобавок.

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

[trdm]

Именно кривой и тормозной.
Могу расказать о последнем баге, который допек.
прислали файл *.xlsx с калькуляцией на одном листе.
На 2-м листе подсчитал кой чего и попробовал распечатать 2 лист.
Он мне выгнал все листы, посмотрел в настройках - стоит печать
текущего листа.
Опять попробовал напечатать: всеравно все листы выгнал.
Ну я его и выкинул. Последняя либра была.

[Александр Руденко]

Всё так, но *.xlsx - это формат MS Office.

[Vladimir]

On 19 сен, 14:09, trdm <trdm...@gmail.com> wrote:
> хто как, а я продолжу заниматься:http://code.google.com/p/unnstudioreport/

Делаешь хорошую вещь.

[trdm]

помог бы кто более умный )) я ж тупой 1с-ник...

[Drake]

Так задачи обозначь - закодим что нужно, не проблема ведь.

[trdm]

On 19 сен, 18:51, Drake <drake.l...@gmail.com> wrote:
> Так задачи обозначь - закодим что нужно, не проблема ведь.

там после рефакторинга надо глюки ловить (((
Бага в расчете ректов страниц после задания масштаба.
Надо лечить (((

[Vladimir]

Пригляделся тут к OpenOffice. Напрямую работать с файлами ods
нежелательно. Не будут работать формулы в шаблоне. Пытаюсь теперь
сделать заполнение шаблоне данными из файла через скрипты.

[Drake]

Я сегодня, наконец, взялся за набросок своей идеи об отчетнике. В
понедельник, крайний срок - вторник - покажу. Может, и без ОО пока
обойдёмся.
Кстати, Vladimir, ты из почты куда пропал?
Разнес код по модулям, с выправлением ссылок, но заливать в текущиую
репу лучше не стоит - конфликт деревьев образуется.
Я в раздумьях - сделать отдельную ветку, или отдельный репозиторий.

[Vladimir]

Хорошо.
Из почты я не пропадал, вроде она у меня работает.
Что случилось с репозитарием? Можно попробовать его удалить и залить
заново.

[drake...@gmail.com]

Нормально всё с репозиторием.

[Drake]

http://narod.ru/disk/26620391001/qreport.zip.html

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

[Владимир Морозов]

28.09.2011 14:14, Drake О©╫О©╫О©╫О©╫О©╫:
> http://narod.ru/disk/26620391001/qreport.zip.html
>
> О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫
> О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫.
> О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫, О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫
> О©╫О©╫О©╫ьёО©╫О©╫О©╫.
> О©╫, О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ xml. О©╫О©╫ О©╫О©╫О©╫ xml-О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫
> XSLT, О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫. О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫.
О©╫О©╫О©╫О©╫О©╫О©╫! О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫. О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ XML О©╫
О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫ XSLT. О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ XSLT О©╫
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫:
1. О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ XSLT, О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫
О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫?
2. О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫? О©╫ О©╫О©╫О©╫
О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ (О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ Qt-О©╫О©╫О©╫О©╫)?
3. О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫
О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ (О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ xls-О©╫О©╫О©╫О©╫)?

О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫.

[drake...@gmail.com]

> 1. С помощью какого инструмента будет создаваться XSLT, сможет ли это делать пользователь с минимальными навыками?
Готовых инструментов не знаю. Пользователь с минимальными навыками? Вряд ли. Задача пользователя с минимальными навыками - создавать шаблоны отчетов.
XSLT преобразования составим уже мы, по одному на каждый нужный формат.
> 2. С помощью чего будет просматриваться документ перед печатью? Я так понял, что это будет браузер (возможно Qt-шный)?
Да, можно браузер, можно RichEdit редактор
> 3. Каким образом мы сможем экспортировать документ в популярные форматы обмена документами (например, у нас все обмениваются xls-ками)?
Для некоторых форматов придётся писать специальный экспорт. Excel, начиная с 2003, ест и XML документы.

[trdm]

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

[Vladimir]

Согласен. Только не надо идею уменьшения зависимости от внешних
инструментов доводить до абсурда. Совсем не зависеть от них мы не
можем.

[drake...@gmail.com]

Отчеты

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

Есть список XSLT-преобразований наших шаблонов в конкретные форматы.
Есть шаблон отчета. Он есть в XML. С любыми инструментами редактирования, которые мы напишем, либо с банальным текстовым редактором.
Шаблон заполняется данными, и мы получаем отчет. Всё ещё в XML.
К отчету применяется XSLT-преобразование, и мы получаем отчет в нужном формате.
С полученым отчетом пользователь делает всё, что ему пожелается.

Внешние зависимости

Я предпочел бы для максимального количествка задач взять готовый инструменты.
В контексте отчетов пошёл бы, даже, на оживление/поддержку давно умершей открытой версии NCReports.
Плюс, есть
http://rlib.sicompos.com/download.php
http://www.xtuple.com/openrpt

Давайте сейчас определимся, мы будем придумывать свой, особенный велосипед, или удовлетворимся существующими?
Я за существующий.

[Vladimir]

Нашел такой отчетник: http://prog.org.ru/wiki/index.php?title=Exaro
Из плюсов:
1. Встраивается в приложение.
2. Скрипты позволяют заряжать любые переменные для отчета.
3. Легко подключить к нашим моделям данных.
4. Как там написано: "Имеет визуальный редактор отчётов и предпросмотр
сгенерированных отчётов с возможностью поиска и экспорта в различные
форматы."

Надо позырить.

[Drake]

OpenRPT
1. DLL-ку легко можно использовать из приложения
2. Понимает как переменные так и запросы.
3. Есть визуальный построитель отчета.
4. Есть предпросмотр.
5. Есть экспорт, как минимум, в PDF

А еще он умеет кросс-таблицы, хотя это задача не отчетника, а СУБД. Но
кому-то будет приятно, наверное.

NCReport (те исходы, что еще живут под открытой лицензией)
1. DLL-ку легко можно использовать из приложения
2. Понимает как переменные так и запросы.
3. Есть предпросмотр.
5. Есть экспорт, как минимум, в XML

Вывод - NC придётся допиливать, нео ему в плюсы идёт наглыдный и
понятный код. OpenRPT можно брать искаропки.

[Drake]

Но ему в плюсы.
надо больше спать.

[Vladimir]

Ну и к какому варианту склоняешься? Мне OpenRPT чисто внешне показался
несколько более основательным чем другие.

[drake...@gmail.com]

Я к нему и склоняюсь.
По иксаре что скажешь?

[Vladimir]

Мне показался там не доработанным и не очень удобным визуальный
построитель отчета. Конечно, это сугубо на мой взгляд. Пока нет
времени поковыряться с ним подольше.

[drake...@gmail.com]

Я его тоже посмотрю тогда.
Пока что голосую за OpenRPT.

[villager]

смотрю сейчас openErp (на питоне)
там отчеты сделаны так:
шаблон набирается в ОО (формат sxw)
затем перегоняется в RML (xml )

при запуске компонуется с данными

http://doc.openerp.com/v6.0/developer/3_11_reports/11_1_openoffice_report.html

[villager]

sorry
думал что sxw2rml exe-файл
оказалось питоновский файл, да еще с нужно инсталлировать костыли

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

[Vladimir]

> неудобная схема, в топку

Чем эта схема неудобная?

[villager]

> Чем эта схема неудобная?
ручным преобразованием sxw2rml
наверное были причины чтобы не делать это на лету (возможно для
быстродействия), но все равно неудобно
да и шаблон редактировать в ОО тоже не сахар - в клетку можно
вписывать достаточно сложные выражения,
но сервиса никакого
лучше бы ограничиться метками, а выражения писать в нормальном
скрипте, а не в тесной ячейке шаблона

но это я так, ворчу
привык к хорошему

[Сергей]

Здравствуйте, сообщество.
А чем не устраивает готовый код на с++ из Ананаса для формирования
отчетов в ОО, для начала вполне рабочее решение.

Плюс универсальную выгрузку данных в ОО из табличных форм (с
закреплением шапки, фильтров, итогами) - покроет 60% промежуточных
отчетов пользователей. Вот аналогичный пример
http://www.sql.ru/forum/actualthread.aspx?tid=464426&pg=1&mid=4546706#4546706,
тока Delphi+Excel.XML

[Drake]

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

[Сергей]

Прошу прощения, если чего-то пропустил в обсуждении, просто если из
ананаса выдрать библиотеку для построения отчета:
1. уже готовый С++ исходный код
2. в качестве шаблона берет файл *.odt или *.ods
3. распаковывает шаблон в отдельную папку, самостоятельно распарсивает
XML
4. заполняет данными (кажись и итоги считает)
5. сворачивает обратно в zip
6. вызывает программу (не обязательно ОО) для открытия готового *.odt
или *.ods файла

Куда еще проще то?

[Vladimir]

On 10 окт, 12:08, Сергей <sergeygershkov...@gmail.com> wrote:
> Прошу прощения, если чего-то пропустил в обсуждении, просто если из
> ананаса выдрать библиотеку для построения отчета:
> 1. уже готовый С++ исходный код
> 2. в качестве шаблона берет файл *.odt или *.ods
> 3. распаковывает шаблон в отдельную папку, самостоятельно распарсивает
> XML
> 4. заполняет данными (кажись и итоги считает)
> 5. сворачивает обратно в zip
> 6. вызывает программу (не обязательно ОО) для открытия готового *.odt
> или *.ods файла
>
> Куда еще проще то?

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

[drake...@gmail.com]

Кстати о.
Какой отчетник будем использовать?

[Vladimir]

On 10 окт, 14:43, drake.l...@gmail.com wrote:
> Кстати о.
> Какой отчетник будем использовать?

OpenRPT. Я тут немного подчищаю код приложения, но пора бы и за
отчетник браться. Нужен класс-интерфейс к отчетнику, который будет
получать контекст печати и запускать отчетник.

[Vladimir]

Что-то типа ТЗ подготовить?

[trdm]

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

Тогда наверное есть смысл и мне доделывать свой, что-бы иметь еще один
запасной вариант.
если мы пишем КОНКРЕТНУЮ задачу, тогда не будет сложности в заполнении
отчета,
были бы данные, а алгоритм вывода запрограммировать можно.

[Сергей]

>
>... Затем

> решил все же отказаться от этого варианта, т.к. не представляю себе,
> как он будет работать с формулами ОО.

Формулы конечно удобно, но достаточно и без них, можно все
предварительно рассчитать и передавать в шаблон в готовом виде (мы у
себя так и делаем).
Если нужно подбивать промежуточные итоги, формулы тут не помогут, для
этого на шаблоне указывается служебное слово (типа "sum") , которое
обрабатывает сам механизм отчета

> Теперь у меня есть вариант, когда заполнение данными делает сам ОО с помощью макросов. Вполне

> рабочий и формулы в нем тоже работают...
Такой вариант мене нравится, сам я вдохновился еще в 2003, когда
появился http://www.terasoft.ru/ru/pages/xlreport.phtml. Там был
реализован полный функционал, которые могут предоставить электронные
таблицы. Отчеты формируются напрямую из Excela либо через OLE. Все
красиво и удобно, НО, видимо жадность погубила....Тока для такого
варианта необходимо понижать безопасность макросов, что не всегда
хорошо для клиентской станции.

Вообще знаю тока 4 варианта отчетника
1. Полная генерация XML из кода программы - идеально подходит для
промежуточных табличных отчетов по заголовкам колонок грида (пример
http://www.sql.ru/forum/actualthread.aspx?tid=464426&pg=1&mid=4546706#4546706).
Недостаток - сложные шапки с несколькими таблицами создавать не айс...
2. Прямая генерация XML на основе шаблона (например *.odt) - готовый к
использованию из ананаса. Проблема больше не из-за отсутствия формул.
При прямом парсинге XML встречаются уникальные комбинации тегов,
которые ну никак не ожидал встретить, отловить их сложно, но можно...
Вариант испытан на практике.
3. Генерация XML через API (OLE, UNO и др.) на основе шаблона
(например *.odt) - готовое решение у тебя есть (посмотреть бы его), но
образец для подражания у меня http://www.terasoft.ru/ru/pages/xlreport.phtml.
Недостаток - зависимость от сторонних библиотек и программ.
4. Генерация отчета в графическом виде - OpenRPT (FastReport,
CristalReport - как пример реализации). Отличные отчетные системы для
прямой печати на бумагу. Масса возможностей, в т.ч. печать итогов на
каждой странице, чего нормально не реализуешь в предыдущих вариантах.
Недостаток - сложная реализация и непредсказуемый результат при
выгрузке в стандартные форматы документов.

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

[Сергей]

Извиняюсь, много наговорил...попробую сформулировать мысль
Хорошо, когда прикладной программист имеет выбор системы отчетности
(чтобы покрыть свои потребности мы, например, используем 1, 2 и 4
варианты отчетов одновременно).

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

В этом случае собственная opensource система отчетности
совершенствуется параллельно, а пользователь для уникальных задач
сможет использовать любой (даже проприетарный) аналог не меняя всей
ERP системы

[Vladimir]

On 10 окт, 21:23, Сергей <sergeygershkov...@gmail.com> wrote:
> Для этого достаточно создать базовый класс отчетности, который
> принимает входящие наборы данных и путь к шаблону отчета. Реализация
> для каждой системы отчетности оформляется в отдельном классе.

Именно так я себе это и представляю. Полностью с Вами согласен.

[trdm]

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

[trdm]

> т.е. идет работа не только с таблицами а с сушностями + универсальные
> алгоритмы задействованы - после вывода строки, пеед выводом строки и
> т.п.

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

[Сергей]

> Я вполне себе представляю работу пользователей с отчетностью и знаю
> как они любят разнообразные плюшки:

Именно по этому мы используем у себя 3 механизма отчетов
1. Аналитический отчет - пользователю нужно проанализировать данные,
быстро что-то убрать, что-то выделить, куда-то вставить, распечатать.
Для решения используем табличную экранную форму с возможностью
сортировки, фильтрации, поиска, выделения цветом, итогов и выгрузкой в
Excel (некода в чистый ОО переделать) повторяющей формат ячеек, ширину
столбцов, итоги с экранной формы. Пользователь анализирует данные на
экранной форме и может выгрузить в Excel c красивой таблицей,
фильтрами, итогами (формулы Excel) и сразу печатать. Не гарантируется
только, что отчет уместится на одном листе. Никакого шаблона нет,
какая таблица на экране, такая получается в Excele

2. Для печати первичных документов и отчетов в вышестоящие инстанции
используем выгрузку в ОО с шаблоном. Редактировать отчет можно, но не
так удобно как в первом варианте, и формул на шаблоне нет, но всегда
есть кнопка чтобы воспользоваться первым вариантом.

3. Бывают отчеты, которые не реализуются OO-Excel (например, итоговые
строки на каждой странице), такие тяжелые отчеты делаем через Crystal
Reports

4. Для первого варианта алгорим реализуется один раз. Для второго и
третьего случая (и других отчетных систем) можно использовать единый
базовый класс

[trdm]

On 11 окт, 19:08, Сергей <sergeygershkov...@gmail.com> wrote:
> > Я вполне себе представляю работу пользователей с отчетностью и знаю
> > как они любят разнообразные плюшки:
>
> Именно по этому мы используем у себя 3 механизма отчетов

что значит "мы используем у себя"? "У себя" - это где?

[Сергей]

> "У себя" - это где?

По основному месту работы c 2004г. разработали собственную систему учета Delphi+Postgres. Теперь рассматриваем варианты новой платформы 

[Drake]

Да, было бы неплохо.

On 10 окт, 15:06, Vladimir <MorozovVladi...@mail.ru> wrote:
> Что-то типа ТЗ подготовить?

[Сергей]

Для своих потребностей я бы иметь два типа отчётов:

I-тип. Для одной таблицы БЕЗ ШАБЛОНА с прямой генерацией XML

На входе:
1) Заголовок отчёта
2) Перечень столбцов с указанием
2.1) Заголовков
2.2) Порядка сортировки
2.3) Ширины столбцов
2.4) Стиля отображения данных (текст, число, логич. значение, дата)
2.5) Итоговой функции (сумма, количество, среднее значение, ...).
3) Надписи в колонтитулах отчёта (кто, когда сформировал отчет)
4) Табличный набор данных

На выходе стилизованный файл *.ods или *.xlsx:
1) Заголовок отчёта со второй строчки с первого столбца в объединённых ячейках на всю ширину таблицы
2) Заголовки столбцов через строчку ниже заголовка отчета
3) На заголовках столбцов установлен "Стандартный фильтр" для файлов *.ods и *.xlsx
4) Между заголовком столбцов и данными установлено "Закрепление области"
5) Данные отображаются в соответствии с указанным стилем
6) Итоги установлены через строчку ниже данных (не затрагиваются фильтрами), рассчитываются через функцию SUBTOTAL( ) или ПРОМЕЖУТОЧНЫЕ.ИТОГИ() - эти функции пересчитываются при использовании фильтров
7) Надписи в колонтитулах  


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

Реализовав подобный механизм - получаем удобную пользователю автоматическую выгрузку данных из любой табличной формы 

[Сергей]

II-тип. Для многотабличного отчета ПО ШАБЛОНУ

В данном случае, учитывая практику готовых отчётных механизмов, необходимо разработать базовый класс на входе которого:
1) Путь к шаблону (просто текст)
2) Перечень констант (имя; значение) - язык именования констант не имеет значение
3) Перечень таблиц (имя; набор данных) - язык именования таблиц не имеет значение

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

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

[trdm]

On 15 окт, 14:57, Сергей <sergeygershkov...@gmail.com> wrote:
> Для своих потребностей я бы иметь два типа отчётов:
>
> I-тип. Для одной таблицы БЕЗ ШАБЛОНА с прямой генерацией XML
>
> На входе:
> 1) Заголовок отчёта
> 2) Перечень столбцов с указанием
> 2.1) Заголовков
> 2.2) Порядка сортировки
> 2.3) Ширины столбцов
> 2.4) Стиля отображения данных (текст, число, логич. значение, дата)
> 2.5) Итоговой функции (сумма, количество, среднее значение, ...).
> 3) Надписи в колонтитулах отчёта (кто, когда сформировал отчет)
> 4) Табличный набор данных

вот алгоритм, более или менее подходящий, использую его уже лет пяток
в своих разработках.
https://docs.google.com/document/d/1Q9i71E0hhwXzvgRnRk7mJKmp3D_MOIeGHgqOQssbNog/edit?hl=ru
формат вывода зависит от типа ячеек таблицы, который можно узнать из
самой таблицы.
ПС. вы смешиваете работу интерактивное задание настроек отчета и
работу самого рендера.
обычно у отчета куча настроек и фильтров. вы же интерактивное
управление игнорируете.

[trdm]

> ПС. вы смешиваете работу интерактивное задание настроек отчета и
> работу самого рендера.
> обычно у отчета куча настроек и фильтров. вы же интерактивное
> управление игнорируете.

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

>> Реализовав подобный механизм - получаем удобную пользователю автоматическую

выгрузку данных из любой табличной формы.
не самая первоочередная задача - экспорт. самая первоочередная -
печать. это удел 99% отчетов.

[villager]

слишком много хотелок для начала
лучше разбить все это на этапы

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

2) стало лень считать итоги - придумываем описание логики работы
отчета(итоги, группировки, запросы, параметры),
формат хранения, и пишем обработчик,
который перегоняет все это в тексты, далее - п1

3) Надоело хранить шаблон в ОО - придумываем формат описания дизайна,
объединяем с логикой (п.2)
делаем дизайнер.

все дела.

я почти все это прошел, и довольно быстро

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

[trdm]

On 15 окт, 18:23, villager <villa...@tut.by> wrote:
> слишком много хотелок для начала
> лучше разбить все это на этапы
>

> 3) Надоело хранить шаблон в ОО - придумываем формат описания дизайна,
> объединяем с логикой (п.2) делаем дизайнер.

Нафиг этот ОО нам нужен?
Вот тебе дизайнер, формат, и рендер в одном флаконе:
http://image-uploader.googlecode.com/files/unnstudioreport_demo.7z
Там в папке "Тест" готовые печ формы.
Поглючивает конечно, многое еще недоделано.
Но уж лучше я буду исправлять глюки в своем отчетнике, чем в ОО, в
котором черт ногу сломит О_о..

[trdm]

On 15 окт, 22:09, trdm <trdm...@gmail.com> wrote:
> Нафиг этот ОО нам нужен?
> Вот тебе дизайнер, формат, и рендер в одном флаконе:http://image-uploader.googlecode.com/files/unnstudioreport_demo.7z
> Там в папке "Тест" готовые печ формы.

Они в формате xml, формат конечно фигачился по мере разработки, но
можно и доработать.

[Сергей]

> выгрузку данных из любой табличной формы.
> не самая первоочередная задача - экспорт. самая первоочередная -
> печать. это удел 99% отчетов.

У нас около 300 пользователей по 5 человек в бюро, в каждом бюро свои
хотелки и дурелки.

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

А есть отчеты аналитические - исполнители формируют обороты, остатки,
отклонения в разрезе разных аналитик, что-то хотят выделить, показать
руководству, что-то в архив положить. Заранее такую печатную форму
определить сложно. Делаем табличную экранную форму с широкой выборкой
(побольше колонок всяких) с фильтрами итогами и возможностью выгрузки,
далее пользователь либо на экранной форме находит что нужно, либо
выгружает в Excel, удаляет лишнее и печатает или в архивную папку
складывают. Схема 5 лет работает - пользователи привыкли, в любой
табличной форме выгрузку требуют (если вдруг кнопку скроем :-)

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

[trdm]

On 15 окт, 23:16, Сергей <sergeygershkov...@gmail.com> wrote:
> А есть отчеты аналитические - исполнители формируют обороты, остатки,
> отклонения в разрезе разных аналитик, что-то хотят выделить, показать
> руководству, что-то в архив положить. Заранее такую печатную форму
> определить сложно. Делаем табличную экранную форму с широкой выборкой
> (побольше колонок всяких) с фильтрами итогами и возможностью выгрузки,
> далее пользователь либо на экранной форме находит что нужно, либо
> выгружает в Excel, удаляет лишнее и печатает или в архивную папку
> складывают. Схема 5 лет работает - пользователи привыкли, в любой
> табличной форме выгрузку требуют (если вдруг кнопку скроем :-)

Ну это у вас так сделано.
У меня есть такой широкий отчет: "Планирование закупок" там
показателей штук 30.
Все показатели регулируются списком с пометками: есть пометка -
выводить, нет, не
выводится и не расчитывается (если нет зависимостей).
Отчеты в 1С легко редактируются и экспортируются, надо отредактировать
- снял
рид онли с таблицы, и редактируй на здоровье. Эксель - тут лишнее.
единственная вещь для которой ексил используется, если надо
пересортировать
отчет. Но тут и в 1С у меня сортировки понастроены - юзер может
выбрать сортировку на
момент создания.
Я так полегаю, что отчетная система у вас немного недоработана - вот и
приходится
вам пользоваться дополнительным костылем.

[Drake]

Призываю в топик создателя проекта.
Как там с ТЗ на отчеты?
Ибо, алилуйя, я разгрёбся с завалом на работе, и готовписать отчетник.

[Vladimir]

ТЗ будет простое. Берем файл
https://docs.google.com/leaf?id=0ByTsPnuzNr-BMzRkNTQxZmItMTgxNi00ZDE0LWI0MDAtYTBkNjdjZmY0Zjcw&hl=ru&authkey=CJjF7IgK.
Это входные данные модуля печати, которые генерирует ядро. В нем в
каждой строке содержится 2 значения. До первой точки с запятой - имя
поля. После точки с запятой - значение поля. И берем шаблон в XML
файле. По умолчанию шаблон пустой.
Далее. Если шаблон пустой (при первом запуске шаблона), запускается
дизайнер отчета, с помощью которого пользователь создает из списка
полей во входном файле шаблон документа. Затем пользователь сохраняет
непустой шаблон и выходит из программы.
При последующем запуске с непустым шаблоном модуль печати заполняет
шаблон входными данными и открывает предпросмотр готового документа.
Далее печать и выход.
Предлагаю для начала создать шаблон типа такого
https://docs.google.com/leaf?id=0ByTsPnuzNr-BZTBmNTVjMzMtYjA1ZS00ZWY5LTkxOGQtMGM4NzU0MGNhYzE0&hl=ru

[villager]

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

по шаблону:
строка таблицы может быть многострочной. Без управляющих тегов не
обойтись.
например
[таблица]
[данные1] [данные2] [данные3]
[данные4]
[/таблица]
при сборке участок между [таблица] [/таблица] заполняется данными пока
есть строки с тегом "таблица" во входном файле

и еще тема подзаголовков/подитогов не раскрыта
в шаблоне теги для подзаголовков/подитогов должны быть внутри
[таблица] [/таблица]
шаблон может выглядеть так
[таблица]
[заг2]
[/заг2]
[заг1]
[/заг1]
[данные1] [данные2] [данные3]
[данные4]
[итог1]
[/итог1]
[итог2]
[/итог2]
[/таблица]
ну и данные:
[заг2]...
[заг1]...
[таблица]...
[таблица]
[таблица]
[итог1]
[заг1]
[таблица]
[таблица]
[таблица]
[итог1]
[итог2]

и т.д.

[trdm]

Похоже у вас просто зуд творчества.

[Vladimir]

On 17 окт, 13:58, trdm <trdm...@gmail.com> wrote:
> Похоже у вас просто зуд творчества.

Это замечательный зуд.

[Vladimir]

On 17 окт, 11:45, villager <villa...@tut.by> wrote:
> по входному файлу:
> повторяющая часть будет определяться по слову "таблица"?
> тогда зачем там номер строки (придется делать лишние движения при
> парсинге)
> достаточно тег "таблица" расположить в начале, а все данные строки
> таблицы разместить на одной строке
> переменные сделать проще:
> имя:значение; имя:значение;...

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

> по шаблону:
> строка таблицы может быть многострочной. Без управляющих тегов не
> обойтись.
> например
> [таблица]
> [данные1] [данные2] [данные3]
>                     [данные4]
> [/таблица]
> при сборке участок между [таблица] [/таблица] заполняется данными пока
> есть строки с тегом "таблица" во входном файле

Это все можно решить путем расширения имени через точку или другой
знак. Например так:
таблица1.данные1.имя_поля; значение
XML я предполагаю не использовать, чтобы упростить разбор входного
файла в тех приложениях, в которых разбор XML затруднен.

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

[trdm]

On 17 окт, 14:13, Vladimir <MorozovVladi...@mail.ru> wrote:
> XML я предполагаю не использовать, чтобы упростить разбор входного
> файла в тех приложениях, в которых разбор XML затруднен.

а почему собственно такая зацикленность на сторонних приложениях?
Вроде бы суцельное приложение делаем.
Для табличек нужен всего 1 формат экспорта: в ексил или ОО.
Этим 1-го форматом можно обойтись.

Я так полагаю вы пытаетесь смоделировать язык, который будет работать
в рамках конечной отчетной системы. Или шаблон отчетника?

[villager]

> Это все можно решить путем расширения имени через точку или другой
> знак. Например так:
> таблица1.данные1.имя_поля; значение

> Подзаголовки и подитоги во входном файле задаваться не будут. Их

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

слишком много времени для разработки. быстрого старта не получится.
а смысл выводить содержимое таблиц в текстовый файл?
лучше тогда напрямую с таблицами (запросами) работать.

[Vladimir]

On 17 окт, 15:46, trdm <trdm...@gmail.com> wrote:
> On 17 окт, 14:13, Vladimir <MorozovVladi...@mail.ru> wrote:
>
> > XML я предполагаю не использовать, чтобы упростить разбор входного
> > файла в тех приложениях, в которых разбор XML затруднен.
>
> а почему собственно такая зацикленность на сторонних приложениях?
> Вроде бы суцельное приложение делаем.

Это не зацикленность. Это желание не ограничивать выбор приложений
печати. Встроенных или внешних.

> Для табличек нужен всего 1 формат экспорта: в ексил или ОО.
> Этим 1-го форматом можно обойтись.

Каким? XML?

> Я так полагаю вы пытаетесь смоделировать язык, который будет работать
> в рамках конечной отчетной системы. Или шаблон отчетника?

Речь идет только о формате передачи печатаемых данных в модуль печати.
Если есть желание назвать это языком - пожалуйста. Шаблон может быть
любой.

[Vladimir]

> слишком много времени для разработки. быстрого старта не получится.

Не вижу, в чем тут проблема. Почему нужно много времени для
разработки? Поясните.

> а смысл выводить содержимое таблиц в текстовый файл?
> лучше тогда напрямую с таблицами (запросами) работать.

Сравним время записи в локальный файл со временем получения данных от
сервера. В большинстве случаев первое время будет значительно меньше.
Не согласны? Кроме того, в этом случае нужно заново (вручную?)
создавать запросы к БД для каждого отчета. Зачем, если они
генерируются ядром? Не проще ли от него получить уже готовые данные?
Плюс к тому мы можем перед передачей данных на печать обработать их с
помощью скриптов, оперирующих нашей объектной средой. А если это будет
внешнее приложение, в котором делается SQL запрос к БД, то как
произвести дополнительную обработку полученных из запроса данных
используя нашу объектную среду?

[trdm]

On 17 окт, 16:15, Vladimir <MorozovVladi...@mail.ru> wrote:
> > Я так полагаю вы пытаетесь смоделировать язык, который будет работать
> > в рамках конечной отчетной системы. Или шаблон отчетника?
>
> Речь идет только о формате передачи печатаемых данных в модуль печати.
> Если есть желание назвать это языком - пожалуйста. Шаблон может быть
> любой.

Для меня пока модуль печать это класс на с++/Qt
В который собственно не надо передавать ничего кроме строковых данных.
У меня печать вот так выглядит:
QFrame m_Dlg;
uoReport::uoReportView* m_GR = new uoReport::uoReportView(&m_Dlg);
uoReport::uoReportDoc* doc = m_GR->getControl()->getDoc();
QFile file("reference.txt");
if (file.open(QIODevice::ReadOnly | QIODevice::Text)){
QTextStream in(&file);
QChar ch = '\t';
QStringList list;
QString line, linePart;
bool oldCC = doc->enableCollectChanges(false);
bool oldDF = doc->enableFormating(false);
int row = 1;
while (!in.atEnd()) {
QString line = in.readLine();
list = line.split(ch);
for (int y=1; y<=list.size(); y++){
linePart = list.at(y-1);
doc->setCellText(row,y,linePart);
doc->setCellTextAlignment(row,y,uoReport::uoVA_Center,
uoReport::uoHA_Left, uoReport::uoCTB_Transfer);
}

++row;
}
doc->enableCollectChanges(oldCC);
doc->enableFormating(oldDF);
}
m_GR->getControl()->optionShow(true, true, true, true);
m_GR->getControl()->doFixedView(2,2);
m_GR->getControl()->setFocus();
// doc->printDoc(true); // если нужна печать
-----------------------------------------------------------
т.е. заполнять в рукопашную. Т.е. на тот момент, когда вы только
заполняете ваш непонятно зачем нужный шаблон, я уже наполняю
документ, который можно хоть отредактировать, хоть распечатать,
хоть посмотреть. Достаточно установить его во вьюху и скомандовать
вьюхе с пом. контекстного меню.

[trdm]

On 17 окт, 16:29, Vladimir <MorozovVladi...@mail.ru> wrote:
> > слишком много времени для разработки. быстрого старта не получится.
>
> Не вижу, в чем тут проблема. Почему нужно много времени для
> разработки? Поясните.
>
> > а смысл выводить содержимое таблиц в текстовый файл?
> > лучше тогда напрямую с таблицами (запросами) работать.
>
> Сравним время записи в локальный файл со временем получения данных от
> сервера. В большинстве случаев первое время будет значительно меньше.
> Не согласны? Кроме того, в этом случае нужно заново (вручную?)
> создавать запросы к БД для каждого отчета. Зачем, если они
> генерируются ядром? Не проще ли от него получить уже готовые данные?

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

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

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

[Vladimir]

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

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

[Vladimir]

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

Вот то, что пользователь видит на экране в форме, например (в терминах
1С) "Реализация товаров и услуг", это свежачок или нет? Что делает
пользователь, если данные слегка устарели? Он нажимает кнопку
"Обновить" и получает самые свежие данные. Почему же я не могу их
отправить на печать? А что тогда пользователь отправит на печать, как
не эти самые данные?

[Vladimir]

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

Вот я за этот широкий горизонт выбора.

[villager]

On 17 окт, 15:29, Vladimir <MorozovVladi...@mail.ru> wrote:
> > слишком много времени для разработки. быстрого старта не получится.
>
> Не вижу, в чем тут проблема. Почему нужно много времени для
> разработки? Поясните.

просто больше времени

> > а смысл выводить содержимое таблиц в текстовый файл?
> > лучше тогда напрямую с таблицами (запросами) работать.
>
> Сравним время записи в локальный файл со временем получения данных от
> сервера. В большинстве случаев первое время будет значительно меньше.
> Не согласны? Кроме того, в этом случае нужно заново (вручную?)
> создавать запросы к БД для каждого отчета. Зачем, если они
> генерируются ядром? Не проще ли от него получить уже готовые данные?
> Плюс к тому мы можем перед передачей данных на печать обработать их с
> помощью скриптов, оперирующих нашей объектной средой. А если это будет
> внешнее приложение, в котором делается SQL запрос к БД, то как
> произвести дополнительную обработку полученных из запроса данных
> используя нашу объектную среду?

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

[villager]

в питоне у меня выполнение отчета выглядит так:

rep=getReportByName("Накладная")
if rep:
rep.param['docsuid']=15
rep.run()

а вот используемый мной формат описания отчета
https://docs.google.com/document/d/10Z8wqJXsiQnt3j5leP6HR7sJs9rlosoik0uzshio8yY/edit?hl=en_US

в нем хранятся и запросы, и шаблон, и скрипты для доп.обработки

[Vladimir]

> не могу понять, зачем еще текстовый локальный файл нужен

Вот тут поймал себя на мысли, что действительно зациклился на этом
файле. Формировать или нет файл - это должен решать модуль печати. В
некоторых случаях это необходимо. А сам модуль печати получает данные
в виде контекста (QMap), о котором мы уже говорили. Спасибо, что
поправил.

[trdm]

собственно пока до них ход не дошел, но это не так сложно сделать, как
остальное.
да это планируется. я работал над рендером-редактором именно для того
что-бы быстрее создавать эти шаблоны.
в последнее время я для своих 1С-ных отчетов использую всего 2-3
шаблона отчетов - нет смысла больше, ониотличаются только наборами
колонок, а колонки пристыковывать 1С-ко позволяет.
ну еще цветом отличаются немного.