Добрый день,
Позвольте предложить некоторые идеи.
1)
Блоки
Базовыми объектами шаблонов/отчётов является блоки.
Блоки могут иметь собственное оформление: borders, backgroun pictures и paddings и т.п.
Блоки могут в себя включать другие блоки, и бывают трёх типов:
— вертикальный блок
— горизонтальный блок
— ячейка
Вертикальные/горизонтальные блоки размещают свои субблоки соответственно вертикально/горизонтально.
Ячейки не могут иметь субблоков, но зато умеют отображать информацию — тексты, картинки etc.
Причём, в вертикальных блоках могут располагаться только горизонтальные и наоборот.
Такие ограничения практически не уменьшают гибкости, но здорово упрощают управление взаимным размещением объектов.
Субблоки в блоках не могут располагаться в произвольных местах, как в большинстве известных ГО.
Напротив, размещаются они исключельно side by side, ну возможно, с "прилипанием" влево или вправо.
Фактически, такая структура аналогична таблицам Word или html.
2)
Переменные
Текст в ячейках шаблона, не обрамлённый в [], выводится as is.
Если же часть (или весь) текст ячейки заключён в скобки [], то
— этот текст считается именем
переменной, {ValueName}
— при генерации отчёта, будет заменён значением взятым из пользовательских данных, согласно
<{ValueName}={Value}/>
3)
Именованые блоки
Некоторые вертикальные/горизонтальные блоки могут
именованы.
При генерации отчёта, блок из шаблона выводится всегда, когда выводится и его владелец. За исключением именованых блоков, которые сидят и ждут специального указания от пользовательских данных.
4)
Пользовательские данные
Данные от клиента поступают в виде, подобно такому:
<Report>
<Date="10.12.2003"/>
<Title="Hello, Report!"/>
<Row>
<ID="1"/>
<Name="Ben"/>
<Amount="100"/>
</Row>
<Row>
<ID="2"/>
<Name="Silver"/>
<Amount="200"/>
</Row>
<Row>
<ID="3"/>
<Name="Flint"/>
<Amount="300"/>
</Row>
<Total="600"/>
</Report>
Элементы такого представления:
1) <{ValueName}={Value}/>
означают, что в некотором месте отчета, именованном как {ValueName} будет подставлено значение {Value}.
2)<{NodeName}>
...
</{NodeName}>
<{NodeName}>
...
</{NodeName}>
означает, что в отчёте будет повторно выведены
именованые блоки из шаблона, с постановкой соответствующих значений (1). И наоборот, если в пользовательских данных не упоминается какой-либо {NodeName}, то соответствующие блоки в результирующем отчёте не появятся.
3) Значения самого верхнего уровня
<Report>
<Date="10.12.2003"/>
<Title="Hello, Report!"/>
...
</Report>
присваиваются и выводятся всегда.
Пример:
Шаблон отчёта
Для удобства, горизонтальные блоки имеют синюю рамку, вертикальные — зелёную.
Ячейки залиты желтым.
Размеры блоков (по крайней мере, пока) задаются исключительно размерами внутренних ячеек.
Если внутренних ячеек нет, то пустой блок просто принимает дефолтные размеры.
Структура шаблона может быть представлена так:
<Report>
<Value=Title/>
<Value=Date/>
<Value=Total/>
<Row>
<Value=ID/>
<Value=Name/>
<Value=Amount/>
</Row>
</Report>
где блокe, содержащему [ID][Name][Amount] присвоено имя "Row"
По следующим данным
<Report>
<Date="10.12.2003"/>
<Title="Hello, Report!"/>
<Row>
<ID="1"/>
<Name="Ben"/>
<Amount="100"/>
</Row>
<Row>
<ID="2"/>
<Name="Silver"/>
<Amount="200"/>
</Row>
<Row>
<ID="3"/>
<Name="Flint"/>
<Amount="300"/>
</Row>
<Total="600"/>
</Report>
должен получится следующий отчёт:
Примечания.
1). Достоинство выбранной схемы размещения визуальных элементов отчёта, имхо, в том, что:
— вложенность блоков позволяет:
— любую ветку отчёта/шаблона рассматривать как самостоятельный отчёт/шаблон. И наоборот
— любой отчёт/шаблон использовать как элемент другого отчёта/шаблона. Поэтому я сознательно в описании не упоминал такие вещи, как подотчёты, crosstab'ы и т.п. Очевидно, что они очень легко реализуются "сверху/сбоку"
— "слипшиеся" блоки-соседи
очень легко (пере)форматировать, при
кажущемся уменьшении гибкости в управлении расположением.
2) xml, как переносчик структур (пользовательских данных, шаблонов и готовых отчётов), имхо, следует использовать только при "переносе с места на место". Внутри одного приложения, проще и удобнее использовать "самодельные" типы ("прикручивая" к xml
методы, мы к этому и придём). По той же причине предлагается не использовать xslt.
3) Где же FO? Использовать стандарт FO можно для хранения визуальных свойств шаблонов.
4) Нужен редактор шаблонов. И как редактор для студии, и как отдельный компонент,приложение.