Добрый день,
Позвольте предложить некоторые идеи.
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) Нужен редактор шаблонов. И как редактор для студии, и как отдельный компонент,приложение.
Кстати, я поставил и попробовал реализацию этого RDL от самой Microsoft — Reporting Service Beta 2. Очень интересная и мощная вещь скажу я вам. Одно но — дизайнер отчетов работает только в VS.NET. Да и тяжеловесный он — для малых приложений не пойдет. К тому же требует в сети ISS и для хранения БД с шаблонами отчетов MSSQL 2000. Для портала отчетов крупного предприятия — самое то, для настольных приложений...
Предложение — может стоит рассмотреть возможность написания репортера именно для этих целей? Понимающий RDL (тем более он уже есть
), пока без дизайнера, который просто будет рендерить отчет, делать его превью и печать. Экспорт в PDF, Exel, HTML — чуть погодя. В написании я мог бы поучаствовать (но не в организационных делах
), правда опыт в C# у меня пока не большой, но надо когда-то начинать
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А кто в организационных делах будет участвовать? Весь проект висит как раз потому, что организатора нет.
Мм-м... Как-бы это... Организационные дела — это и есть в данный момент моя основная работа, плюс еще написание приложений для PocketPC и MSSQL 2000, так сказать — играющий тренер. Хотелось-бы другого
. Но, насколько я понял, пока идет обмен мнениями и окончательный выбор архитектуры репортера не сделан. Как только он будет сделан — можно начать сколачивать группу исполнителей. Поскольку только после выбора архитектуры многие потенциальные исполнители окончательно определятся — участвовать в проекте или нет. Например, меня интересует в первую очередь реализация объектной модели RDL на C# применительно к Windows Forms. У кого-то другие предпочтения. Кто-то должен сделать выбор. Вот у меня вопрос — кто этот "кто-то"?
