Здравствуйте, Ved, Вы писали:
ВВ>>>> можно прорисовывать вручную через GDI+ или руками конвертить в ХТМЛ и использовать для просмотра браузер (хотя этот вариант мне не особо по душе). Ved>Лучше с HTML-представлением не связываться — ты представляешь, как его качественно распечатать? Я — нет. Через WebBrowser control качественно не получится. Под качеством я понимаю одинаковую работу независиио от принтера и пр. внешних условий.
Конечно, ХТМЛ не создан для печати, но если правильно построить документ — не используя position:absolute и пр., то проблем быть не должно . Со своими аки отчетами на ХТМЛе у меня проблем не было по кр. мере. Хотя печатал на куче принтеров, через ахБраузер. Могу даже попытаться вспомнить что за принтеры. Просто уж очень много вкусностей дает ХТМЛ.
ВВ>>ОК. Попробуем разобраться. Предложенная тобой схема выглядит так: XML -> XML -> XSL:FO ВВ>>Может, я что и не допонял, но получается, что работа репортера завязана на конкретном формате. Ved>В смысле? завязка вообще-то на xsl:fo, а это стандарт, что дает некоторые преимущества. В при изменении и разных версиях шаблонов отчета надо будет просто добавить новое xslt-преобразование. ВВ>>Собственно, основное различие как раз в том, что я предлагаю вместо этого использовать граф объектов, что позволит максимально абстрагириваться от любого формата в принципе. Т.е схема уже будет выглядеть так: XML|DataSet -> reportDocument -> ... Ved>Ок. А как насчет экспорта в другие форматы? doc? rtf? pdf? xls? Причем офиса и пр. может на машине и не быть... А так можно было бы использовать уже существующие.
Я не против стандарта, я против, извиняюсь за каламбур, включения стандарта в стандарт. Можно работать с графом, и уже _на_основе_его_ генерить xsl:fo
Ved>А вообще — везде свои плюсы и минусы. Это надо смотреть по трудозатратам. Кроме того, граф объектов отрисовать на не так просто в отчете будет. Это надо хорошо движок проектировать. Граф будет в любом случае, вопрос — какой... Уже пробовал графы отрисовывать для отчета. При отрисовке нельзя забывать, какая страница, какие поля, какая разбивка, где нужны какие пункты... Движок должен быть очень грамотно реализован и событий с их обработчиками там будет предостаточно.
100% согласен. Я когда начинал копаться с тем же принтДокумент, у меня поначалу вызывало затруднение даже распечатке текста без разделения на строки. Но ведь никто и не говорил, что будет легко
Здравствуйте, Воронков Василий, Вы писали:
AVK>>ИМХО как раз весьма критично. В случае стандартного решения у пользователя всегда есть возможность заменить куски нашей системы, поскольку формат данных между ними стандартизован.
ВВ>Так вот насколько критично наличие такой возможности у пользователя?
Если не забывать о том что пользователь это программист то довольно критично.
AVK>>Который формат ты имеешь ввиду?
ВВ>Формат данных, пользуясь твоим выражением.
На формат данных не завязан. На формат входных данных завязан только конкретный шаблон.
AVK>>Граф объектов это тоже формат, только формат не данных, а формат интерфейсов.
ВВ>Ну можно и так сказать. Вот как раз данная модель мне и кажется более удачной.
Чем?
ВВ>Основная логика будет вообще никак не связана с тем, что ты называешь форматами данных.
Ничего не понимаю. Каким образом твои данные попадут в граф шаблона?
ВВ>То есть вместо того, чтобы работать с хмл и его объектной моделью, мы будем работать с объектной моделью собственно графа.
Ну и чем это лучше кроме изобретения велосипеда?
ВВ>Что позволяет четко отделить 1) представления, 2)собственно сам "отчет", 3)"формат" отчета(доп., результат сериализации).
Он и так четко отделен.
ВВ>А это как раз хорошо. Позволит сделать систему более масштабируемой. XML — это далеко не единственный вариант, к-й можно использовать.
Если ты о входных данных, то средствами дотнета XML можно легко получить из DataSet. По сути тот же граф.
ВВ> Можно сохранять через бин. форматтер, отрисовывать самому,
Что то я никак тебя не пойму. То ты про входные данные, то ты про шаблоны, теперь уже про данные для отрисовки. Какая то у тебя каша получается. Итак есть вполне отдельные сущности:
1) Входные данные
2) Шаблон отчета
3) Готовый отчет
О формате чего ты речь ведешь? Какой формат должна иметь каждая из этих сущностей?
ВВ>Если не использовать граф, то всю логику в принципе придется переписывать.
Да ну?
AVK>>Ничуть
ВВ>Ну мне кажется, что ХТМЛ все же упрощает некоторые задачи — например, легко разделить данные и представления посредством CSS.
И что? Зачем ее разделять в уже готовом отчете?
ВВ>Возможность, устанавливать Layoutы, комбинировать разные на одной странице.
Здравствуйте, Ved, Вы писали:
Ved>1) Юзер хочет просмотреть отчет перед печатью. Ved> а) запрашивается шаблон
Да
Ved> б) заполняем шаблон данными
Да
Ved> в) преобразования до xsl:fo
Да
Ved> г) Юзер ждет окна с внешним видом отчета. Кто его покажет? .NET или Java-вский конвертер?
Ни тот и не другой, а например Acrobat Reader .
Ved>2) Юзер отправляет на печать Ved> а) .... Ved> б) .... Ved> в) .... Ved> г) Кто печатает отчет вместе со всеми настройками?
ВВ>Хотя печатал на куче принтеров, через ахБраузер.
А что это за контрол? какая у него лицензия? Если он платный, то уже не подходт априори. У тебя в отчетах была многоколоночность с разбивкой на страницы (т. е. чтобы можно было вывести только одну какую-то страницу, или диапазон, список оных?) Причем многоколоночность такого плана:
Страница 1
Колонка 1 начало Колонка 2 начало
1 4
2 5
3 6
Колонка 1 конец Колонка 2 конец
Страница 2
Колонка 1 начало Колонка 2 начало
7 10
8 11
9 12
Колонка 1 конец Колонка 2 конец
Форматирование иной раз может быть намного более сложным...
Мне вообще интересно = ахБроузер может сказать тебе — сколько в печатной странице у него строк? Что поместится, а что нет? А если юзеру хочется поля поменять или с принтером не совпадут? Как HTML для страницы без этих параметров формировать?
ВВ>Я не против стандарта, я против, извиняюсь за каламбур, включения стандарта в стандарт. Можно работать с графом, и уже _на_основе_его_ генерить xsl:fo
Можно, зато полученный контрол для отображения на основе xsl:fo можно и отдельно использовать — весьма полезная штука получится.
ВВ>100% согласен. Я когда начинал копаться с тем же принтДокумент, у меня поначалу вызывало затруднение даже распечатке текста без разделения на строки. Но ведь никто и не говорил, что будет легко
Вообще — если писать конкретный код для конкретного отчета — все достаточно просто получается, а вот если пытаешься универсально сделать — вот тогда все и начинается
Здравствуйте, AndrewVK, Вы писали:
Ved>> г) Юзер ждет окна с внешним видом отчета. Кто его покажет? .NET или Java-вский конвертер? AVK>Ни тот и не другой, а например Acrobat Reader .
А если надо сделать так, чтобы юзер смотрел только из твоего же приложения и не мог отчет только просмотреть и не мог ни сохранить, ни распечатать, ни Ctrl+C/Ctrl+V сделать? (Print Screen не в счет, хотя в идеале и это было бы неплохо ) Или что-то в этом роде? Такое бывает очень и очень нужно (у нас например такое есть и востребовано (безопасность, так сказать)).
Кроме того, на компе у юзера Acrobat Reader'а может по каким-то причинам не быть, или еще что? Как говорится, желание юзера... Да и запускать отдельное приложение как-то неаккуратненнько получается. Тогда действительно очень хорошо было бы дополнительно сделать свой формат и самим его печатать и просматривать. А преобразования можно было бы и сторонними библиотеками выполнять. Идеально сюда мог бы вписаться еще и сервер отчетов.
Здравствуйте, AndrewVK, Вы писали:
AVK>Что то я никак тебя не пойму. То ты про входные данные, то ты про шаблоны, теперь уже про данные для отрисовки. Какая то у тебя каша получается. Итак есть вполне отдельные сущности: AVK>1) Входные данные AVK>2) Шаблон отчета AVK>3) Готовый отчет AVK>О формате чего ты речь ведешь? Какой формат должна иметь каждая из этих сущностей?
1) Ну тут все более или менее ясно. XML или можно даже напрямую использовать DataSet.
2) Насколько я понял у тебя шаблон отчета — это XML, в котором хранятся как данные, так и общие сведения о представлении. (Где будут храниться детальные сведения о представлении? — цвет границ таблицы, шрифты и пр. Также в шаблоне? Или устанавливаться для всех отчетов сразу?) Я предлагаю использовать здесь не XML, а реализовать класс ReportDocument. по типу
class ReportDocument {
StyleTableCollection Styles { get; } // Коллеция классов, в которых содержится _вся_ информация о представлении
ReportElementCollection ReportElements { get; } // Типизированная коллекция элементов документа. Все они реализуют некий интерфейс
//IElement. [Возможно, даже логика рисовать прописана непосредственно в них]
... // к-нить дополнительные данные }
3)Готовый отчет — это отчет, готовый для представления? Если так, то данное понятие вообще довольно условно. Фактически оптимально рассмотреть здесь наибольшее количество форматов. При этом желательно осуществить поддержку вывода отчета и средствами самого репортера — чтобы пользователь каждый разный акробата не запускал. А для вывода наиболее удобен (==прост) именно ХТМЛ благодаря ВебБраузеру.
ВВ>>Ну мне кажется, что ХТМЛ все же упрощает некоторые задачи — например, легко разделить данные и представления посредством CSS. AVK>И что? Зачем ее разделять в уже готовом отчете?
А ты как предлагаешь настраивать представление отчета? Суть разделения не в нем самом, конечно. А в том, что достаточно сделать нехитрый едитор/генератор CSS и внешний вид отчета будет _полностью_ настраиваемым — причем по весьма удобной модели. Т.е. непосредственно сам процесс генерации ХТМЛ будет вообще абстрагирован от всяких там цветов и рамок. Всем этим будет заниматься отдельный генератор CSS.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>1) Ну тут все более или менее ясно. XML или можно даже напрямую использовать DataSet.
То есть здесь у тебя с моим предложением расхождений нет.
ВВ>2) Насколько я понял у тебя шаблон отчета — это XML, в
XSLT
ВВ> котором хранятся как данные, так и общие сведения о представлении.
Нет там никаких данных, только представление
ВВ>(Где будут храниться детальные сведения о представлении? — цвет границ таблицы, шрифты и пр.
Вот именно там и будут
ВВ> Также в шаблоне? Или устанавливаться для всех отчетов сразу?) Я предлагаю использовать здесь не XML, а реализовать класс ReportDocument.
Зачем??? Зачем сочинять свой собственный DOM, придумывать свою собственную механику заполнения этого шаблона данными? Что ты этим получишь кроме горы работы и нестандартности решения?
ВВ>3)Готовый отчет — это отчет, готовый для представления?
Да
ВВ>Если так, то данное понятие вообще довольно условно. Фактически оптимально рассмотреть здесь наибольшее количество форматов.
А я вот предлагаю xsl:fo, а уж его стандартными средствами конвертировать в разные форматы. В твоем же случае рендерер для каждого формата фактически придется писать заново.
ВВ>При этом желательно осуществить поддержку вывода отчета и средствами самого репортера — чтобы пользователь каждый разный акробата не запускал. А для вывода наиболее удобен (==прост) именно ХТМЛ благодаря ВебБраузеру.
Он абсолютно не годится в качестве универсального решения хотя бы потому что не показывает разбиение на страницы.
AVK>>И что? Зачем ее разделять в уже готовом отчете?
ВВ>А ты как предлагаешь настраивать представление отчета?
В шаблоне.
ВВ>Суть разделения не в нем самом, конечно. А в том, что достаточно сделать нехитрый едитор/генератор CSS
А как же поддержка разных форматов?
ВВ> и внешний вид отчета будет _полностью_ настраиваемым — причем по весьма удобной модели.
Зачем настраивать вид готового отчета? Мало того что это не нужно, иногда это еще и вредно.
ВВ>Т.е. непосредственно сам процесс генерации ХТМЛ будет вообще абстрагирован от всяких там цветов и рамок. ВВ> Всем этим будет заниматься отдельный генератор CSS.
В общем плохая идея. HTML в качестве формата отчетов годится в крайне ограниченных случаях, когда не нужно точное разбиение на страницы и точное расположение элементов на странице. А вся механика о которой ты речь ведешь для других форматов будет просто не задействована.
Я имел в виду ActiveX WebBrowser — движок ИЕ. Многие проблемы с печатью он действительно решает. Есть даже готовый просмотр для страницы, можно выбирать диапазон и пр.
Здравствуйте, Ved, Вы писали:
Ved>А если надо сделать так, чтобы юзер смотрел только из твоего же приложения и не мог отчет только просмотреть и не мог ни сохранить, ни распечатать, ни Ctrl+C/Ctrl+V сделать?
А зачем такое нужно?
Ved>(Print Screen не в счет, хотя в идеале и это было бы неплохо ) Или что-то в этом роде? Такое бывает очень и очень нужно (у нас например такое есть и востребовано (безопасность, так сказать)).
Странное требование. Все равно при желании в экселе все что угодно нарисовать можно.
Ved>Кроме того, на компе у юзера Acrobat Reader'а может по каким-то причинам не быть, или еще что?
Ну значит поставит, раз нет. А ты предлагаешь фактически аналог акробата написать самостоятельно? Можно конечно, но это очень большой объем работ.
Ved>Как говорится, желание юзера... Да и запускать отдельное приложение как-то неаккуратненнько
Почему отдельное приложение? Акробат вполне втыкается в OLE контейнер и ActiveX по моему есть.
Ved> получается. Тогда действительно очень хорошо было бы дополнительно сделать свой формат и самим его печатать и просматривать.
Ну свой то зачем? Тогда уж действительно писать рендерер, рисующий прямо из fo.
Ved> А преобразования можно было бы и сторонними библиотеками выполнять. Идеально сюда мог бы вписаться еще и сервер отчетов.
Здравствуйте, AndrewVK, Вы писали:
AVK>Зачем??? Зачем сочинять свой собственный DOM, придумывать свою собственную механику заполнения этого шаблона данными? Что ты этим получишь кроме горы работы и нестандартности решения?
Кода обещает быть довольно много, соответственно нужно подумать и о дизайне. Если к примеру занимать ручной отрисовкой для отображения отчета в собственном контроле, то благодаря собственному же ДОМу можно использовать ряд интересных решений. Вот например читал я где-то, что в AutoCad все представляемые элементы строго типизированы и непосредственно в их классах содержится логика прорисовки. Довольно красивое решение имхо. К тому же такая модель будет приближена именно к конкретным нуждам.
ВВ>>3)Готовый отчет — это отчет, готовый для представления? AVK>Да ВВ>>Если так, то данное понятие вообще довольно условно. Фактически оптимально рассмотреть здесь наибольшее количество форматов.
AVK>А я вот предлагаю xsl:fo, а уж его стандартными средствами конвертировать в разные форматы. В твоем же случае рендерер для каждого формата фактически придется писать заново.
Собственным ДОМ мог бы быть просто промежуточным звеном между входящими данными и XLST. Подобный граф можно легко сериализовать, сохранив отчет в неком нативном формате. Данный граф явно не привязан ни к каком итоговому формату (пдфы, доки там всякие). И данный граф непосредственно используется при отрисовке отчета средствами самого репортера. Т.е., если полностью забить на ХТМЛ и при этом все же согласиться с тем, что встроенная поддержка просмотра должна быть, то можно построить класс ReportDocument так, что задача отрисовки максимально упростится. Таким образом получится, что отображение отчета средствами репортера != какому-либо его преобразованию.
AVK>В общем плохая идея. HTML в качестве формата отчетов годится в крайне ограниченных случаях, когда не нужно точное разбиение на страницы и точное расположение элементов на странице. А вся механика о которой ты речь ведешь для других форматов будет просто не задействована.
В принципе-то я не спорю, что использование ХТМЛ — довольно кривое решение, но уж очень оно привлекает из-за простоты в некоторых аспектах Имелось в виду, что отображаться отчет будет уметь только в формате ХТМЛ, а сохраняться — еще в ряде других.
По поводу стилей. То есть ты вообще против настраиваемости стилей в какой бы то ни было форме? Я о том, что бы пользоваль мог определить цветовые и пр. характеристики, притом, чтобы они могли ассоциироваться непосредственно с _данным_ отчетом. Модель CSS — именно модель, а не CSS в частности — соответственно, предполагает, что есть некие дефолтовые таблицы стилей, прихватываемые по умолчанию. Но есть возможность и менять их на разных уровнях.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Ved, Вы писали:
Ved>>А если надо сделать так, чтобы юзер смотрел только из твоего же приложения и не мог отчет только просмотреть и не мог ни сохранить, ни распечатать, ни Ctrl+C/Ctrl+V сделать? AVK>А зачем такое нужно?
От юзеров защита — ну понимаешь, заказчик попадается и говорит: "Надо, чтобы юзеры могли вот это, а вот это и это не могли сделать". А рисовать где-то — так на это время надо и много данных так не нарисуешь...
Ved>>(Print Screen не в счет, хотя в идеале и это было бы неплохо ) Или что-то в этом роде? Такое бывает очень и очень нужно (у нас например такое есть и востребовано (безопасность, так сказать)). AVK>Странное требование. Все равно при желании в экселе все что угодно нарисовать можно.
Можно конечно, только вот много не нарисуешь.
Ved>>Кроме того, на компе у юзера Acrobat Reader'а может по каким-то причинам не быть, или еще что? AVK>Ну значит поставит, раз нет. А ты предлагаешь фактически аналог акробата написать самостоятельно? Можно конечно, но это очень большой объем работ.
Не всегда могут согласиться поставить. Увы. А то, что это большой объем работ, так и ежу ясно. По крайней мере редактора писать не надо — разве что дизайнер отчетов.
AVK>Почему отдельное приложение? Акробат вполне втыкается в OLE контейнер и ActiveX по моему есть.
Есть. Только вот он идет с полым Acrobat'ом и денег стоит. И не понимает документов из потока, только из файла.
AVK>Ну свой то зачем? Тогда уж действительно писать рендерер, рисующий прямо из fo.
Можно. Заодно и как отдельный контрол может пользоваться бооольшим спросом.
Ved>> А преобразования можно было бы и сторонними библиотеками выполнять. Идеально сюда мог бы вписаться еще и сервер отчетов. AVK>Это имхо обязательно.
Причем единожды сформированные и хранящиеся в базе отчеты не должны иметь возможности редактирования и должны снабжаться подписью-сертификатом. Но это уже в разряд фич можно поместить.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Я имел в виду ActiveX WebBrowser — движок ИЕ. Многие проблемы с печатью он действительно решает. Есть даже готовый просмотр для страницы, можно выбирать диапазон и пр.
Я не использовал этот контрол для печати, но абстрагируясь от ослика, он не позволяет сказать точно, что на какой странице будет — разве что приблизительно, не позволяет понять, сколько же точно страниц. А выделять мышой — это, имхо, не есть хорошо — может не понравиться. Да и данные тогда оттуда выдрать можно легко будет. Да и предварительного просмотра у него нет — так, как везде в отчетах... Да, это можно попробовать сэмулировать, но по-моему, это тоже достаточно неудобно...
ВВ>Кода обещает быть довольно много, соответственно нужно подумать и о дизайне. Если к примеру занимать ручной отрисовкой для отображения отчета в собственном контроле, то благодаря собственному же ДОМу можно использовать ряд интересных решений. Вот например читал я где-то, что в AutoCad все представляемые элементы строго типизированы и непосредственно в их классах содержится логика прорисовки. Довольно красивое решение имхо. К тому же такая модель будет приближена именно к конкретным нуждам.
Я в экспериментах шел примерно таким же путем — список объектов, каждый из которых умеет отрисовываться. Главная проблема — что, где, и когда из объектов должно отрисовываться. Там могут помочь списки с событиями — по событию обрабатывается соответствующий список.
ВВ>По поводу стилей. То есть ты вообще против настраиваемости стилей в какой бы то ни было форме? Я о том, что бы пользоваль мог определить цветовые и пр. характеристики, притом, чтобы они могли ассоциироваться непосредственно с _данным_ отчетом. Модель CSS — именно модель, а не CSS в частности — соответственно, предполагает, что есть некие дефолтовые таблицы стилей, прихватываемые по умолчанию. Но есть возможность и менять их на разных уровнях.
Стили — вещь хорошая и нужная, только реализовать их тоже лучше в xml, если только не связываться с HTML'ем.
Здравствуйте, Ved, Вы писали:
Ved>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Кода обещает быть довольно много, соответственно нужно подумать и о дизайне. Если к примеру занимать ручной отрисовкой для отображения отчета в собственном контроле, то благодаря собственному же ДОМу можно использовать ряд интересных решений. Вот например читал я где-то, что в AutoCad все представляемые элементы строго типизированы и непосредственно в их классах содержится логика прорисовки. Довольно красивое решение имхо. К тому же такая модель будет приближена именно к конкретным нуждам. Ved>Я в экспериментах шел примерно таким же путем — список объектов, каждый из которых умеет отрисовываться. Главная проблема — что, где, и когда из объектов должно отрисовываться. Там могут помочь списки с событиями — по событию обрабатывается соответствующий список.
Возможно, здесь даже не будет надобности в событиях. Будет последовательный разбор документа и соответствующая отрисовка. (Если все же рисовать по собственному графу, то это легче всего сделать, как я говорил, сабклассировав PrintDocument).
ВВ>>По поводу стилей. То есть ты вообще против настраиваемости стилей в какой бы то ни было форме? Я о том, что бы пользоваль мог определить цветовые и пр. характеристики, притом, чтобы они могли ассоциироваться непосредственно с _данным_ отчетом. Модель CSS — именно модель, а не CSS в частности — соответственно, предполагает, что есть некие дефолтовые таблицы стилей, прихватываемые по умолчанию. Но есть возможность и менять их на разных уровнях. Ved>Стили — вещь хорошая и нужная, только реализовать их тоже лучше в xml, если только не связываться с HTML'ем.
Стили в предлагаемом мной варианте — это типизированная коллекция классов, к-я будет просто сериализоваься — возможно в тот же хмл. Стили будут являться частью графа.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Кода обещает быть довольно много, соответственно нужно подумать и о дизайне. Если к примеру занимать ручной отрисовкой для отображения отчета в собственном контроле, то благодаря собственному же ДОМу можно использовать ряд интересных решений. Вот например читал я где-то, что в AutoCad все представляемые элементы строго типизированы и непосредственно в их классах содержится логика прорисовки. Довольно красивое решение имхо.
И жутко негибкое. Сложно добавить новый элемент. Практически невозможно изменить целевое устройство для отрисовки.
ВВ> К тому же такая модель будет приближена именно к конкретным нуждам.
Пока что я слышу одни красивые лозунги и никаких конкретных аргументов.
AVK>>А я вот предлагаю xsl:fo, а уж его стандартными средствами конвертировать в разные форматы. В твоем же случае рендерер для каждого формата фактически придется писать заново.
ВВ>Собственным ДОМ мог бы быть просто промежуточным звеном между входящими данными и XLST.
А зачем он тогда нужен?
ВВ>Подобный граф можно легко сериализовать,
Ну да, а xml сериализовать куда сложнее.
ВВ> сохранив отчет в неком нативном формате.
Ага, чтобы никто не догадался. Знаешь, когда я слышу слова "свой формат" я тут же сильно пугаюсь, ибо велосипеды-с.
ВВ>Данный граф явно не привязан ни к каком итоговому формату (пдфы, доки там всякие).
А XSLT или XSL:FO разве привязаны? Ты пойми что изобретаешь велосипед. Xml и есть тот самый граф, только не самопальный, а стандартный и уже готовый.
ВВ>И данный граф непосредственно используется при отрисовке отчета средствами самого репортера.
Чем он будет лучше Xml DOM с содержащимся внутри него FO?
ВВ> Т.е., если полностью забить на ХТМЛ и при этом все же согласиться с тем, что встроенная поддержка просмотра должна быть, то можно построить класс ReportDocument так, что задача отрисовки максимально упростится.
Ничем она не упростится. Обработка входных данных это самый маленький кусок. Самое тяжелое в рендерере это т.н. layout engine, который от входного формата мало зависит. Рисовать же объектами, хранящими данные как раз и есть то самое смешивание данных и представления, против которого ты недавно выступал.
ВВ> Таким образом получится, что отображение отчета средствами репортера != какому-либо его преобразованию.
А зачем такое? Зачем лишние цепочки конвеера? Я вобще предполагаю что на начальном этапе вобще рендереры не делать, а использовать готовые. А потом уж, при желании, реализовать свой рендерер FO.
ВВ>В принципе-то я не спорю, что использование ХТМЛ — довольно кривое решение, но уж очень оно привлекает из-за простоты в некоторых аспектах
Форматы, в которые штатно выводит FOP:
PDF
PCL
PostScript
RTF
SVG
AWT (это вьювер, написанный на джаве)
MIF
TXT
А вот теперь прикинь сколько тебе понадобиться человеколет чтобы реализовать отрисовку в эти форматы руками.
ВВ>Имелось в виду, что отображаться отчет будет уметь только в формате ХТМЛ, а сохраняться — еще в ряде других.
То есть про отображение разбиения на страницы можно сразу забыть?
ВВ>По поводу стилей. То есть ты вообще против настраиваемости стилей в какой бы то ни было форме?
На готовых отчетах? Конечно против. А вот при рендеринге пожалуйста — все что нужно это поменять xslt-шаблоны для конкретных примитивов редактора. В разы гибче CSS.
ВВ> Я о том, что бы пользоваль мог определить цветовые и пр. характеристики, притом, чтобы они могли ассоциироваться непосредственно с _данным_ отчетом.
Зачем такое надо? И для чего стили, если все равно речь идет о конкретном документе?
ВВ>Модель CSS — именно модель, а не CSS в частности — соответственно, предполагает, что есть некие дефолтовые таблицы стилей, прихватываемые по умолчанию. Но есть возможность и менять их на разных уровнях.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, AndrewVK, Вы писали:
AVK>>Зачем??? Зачем сочинять свой собственный DOM, придумывать свою собственную механику заполнения этого шаблона данными? Что ты этим получишь кроме горы работы и нестандартности решения?
Да все то же самое. Только custom может получиться быстрее — устаешь от чужик багов.
ВВ>Кода обещает быть довольно много, соответственно нужно подумать и о дизайне. Если к примеру занимать ручной отрисовкой для отображения отчета в собственном контроле, то благодаря собственному же ДОМу можно использовать ряд интересных решений. Вот например читал я где-то, что в AutoCad все представляемые элементы строго типизированы и непосредственно в их классах содержится логика прорисовки. Довольно красивое решение имхо. К тому же такая модель будет приближена именно к конкретным нуждам.
ВВ>>>3)Готовый отчет — это отчет, готовый для представления? AVK>>Да ВВ>>>Если так, то данное понятие вообще довольно условно. Фактически оптимально рассмотреть здесь наибольшее количество форматов.
Конечно условно. Если дизайнер будет сильно зависеть от представления — это, как сказал кто-то, признак плохого дизайна
AVK>>А я вот предлагаю xsl:fo, а уж его стандартными средствами конвертировать в разные форматы. В твоем же случае рендерер для каждого формата фактически придется писать заново.
Фигня. Дело не в рендерере даже, а в том, как построить систему, чтобы не наступать везде на одни и теже грабли в виде собою же поставленных (для простоты, типа) ограничений.
ВВ>Собственным ДОМ мог бы быть просто промежуточным звеном между входящими данными и XLST. Подобный граф можно легко сериализовать, сохранив отчет в неком нативном формате. Данный граф явно не привязан ни к каком итоговому формату (пдфы, доки там всякие). И данный граф непосредственно используется при отрисовке отчета средствами самого репортера. Т.е., если полностью забить на ХТМЛ и при этом все же согласиться с тем, что встроенная поддержка просмотра должна быть, то можно построить класс ReportDocument так, что задача отрисовки максимально упростится. Таким образом получится, что отображение отчета средствами репортера != какому-либо его преобразованию.
AVK>>В общем плохая идея. HTML в качестве формата отчетов годится в крайне ограниченных случаях, когда не нужно точное разбиение на страницы и точное расположение элементов на странице. А вся механика о которой ты речь ведешь для других форматов будет просто не задействована.
Это да.
ВВ>В принципе-то я не спорю, что использование ХТМЛ — довольно кривое решение, но уж очень оно привлекает из-за простоты в некоторых аспектах Имелось в виду, что отображаться отчет будет уметь только в формате ХТМЛ, а сохраняться — еще в ряде других. ВВ>По поводу стилей. То есть ты вообще против настраиваемости стилей в какой бы то ни было форме? Я о том, что бы пользоваль мог определить цветовые и пр. характеристики, притом, чтобы они могли ассоциироваться непосредственно с _данным_ отчетом. Модель CSS — именно модель, а не CSS в частности — соответственно, предполагает, что есть некие дефолтовые таблицы стилей, прихватываемые по умолчанию. Но есть возможность и менять их на разных уровнях.
Да будет настраиваемость! Только вот не перед печатью. Хотя... разбивка на страницы, футеры и отступы — чем не настраиваемость?
P>>Здравствуйте, SiAVoL, Вы писали:
ВВ>А есть ли какие собственные идеи по поводу движка? В данном случае это вопрос первостепенной важности. Было бы интересно рассмотреть и другие варианты.
Убереги тебя Бог от всякого движка. Движки, особенно навороченные и глобальные — самое из самых зол. Давайте делать компоненты.
К примеру, есть сериализатор — и пусть он будет просто сериализатор. Без отчетов и расчетов. А всю необходимую кастомность надо вкладывать в классы расширений. ну типа SerializationBinder.
Здравствуйте, Ved, Вы писали:
Ved>От юзеров защита — ну понимаешь, заказчик попадается и говорит: "Надо, чтобы юзеры могли вот это, а вот это и это не могли сделать". А рисовать где-то — так на это время надо и много данных так не нарисуешь...
Ну такого уровня защита в PDF присутствует.
AVK>>Странное требование. Все равно при желании в экселе все что угодно нарисовать можно. Ved>Можно конечно, только вот много не нарисуешь.
А много обычно и не надо
Ved>Не всегда могут согласиться поставить. Увы.
Странно, почему это? Сейчас даже драйвера некоторые акробат ставят.
Ved>А то, что это большой объем работ, так и ежу ясно. По крайней мере редактора писать не надо — разве что дизайнер отчетов.
Ну на первых порах тот же XmlSpy сойдет.
AVK>>Почему отдельное приложение? Акробат вполне втыкается в OLE контейнер и ActiveX по моему есть. Ved>Есть. Только вот он идет с полым Acrobat'ом и денег стоит.
Да нет конечно. Ты в IE пробовал pdf открывать? И никаких полных акробатов. Попробовал сейчас кинуть ActiveX акробатовский на шарповскую форму — вроде бы тоже все работает.
Ved>И не понимает документов из потока, только из файла.
Опять же как тогда он доки из инета показывает? И что означает свойство src контрола?
AVK>>Это имхо обязательно. Ved>Причем единожды сформированные и хранящиеся в базе отчеты не должны иметь возможности редактирования и должны снабжаться подписью-сертификатом. Но это уже в разряд фич можно поместить.
Это уже детали. Главное должен быть сервер, одновременно генерящий отчеты и поддерживающий их очередь. Причем генерящий в том числе и асинхронно.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Возможно, здесь даже не будет надобности в событиях. Будет последовательный разбор документа и соответствующая отрисовка. (Если все же рисовать по собственному графу, то это легче всего сделать, как я говорил, сабклассировав PrintDocument).
Пройденный этап. Гимора и кода было более, чем достаточно. Попробуй — поймешь, о чем я. В конце концов похоронил эту идею. Реализация с событиями более гибка и позволит сделать поддержку плагинов-расширений гораздо более простой.
ВВ>Стили в предлагаемом мной варианте — это типизированная коллекция классов, к-я будет просто сериализоваься — возможно в тот же хмл. Стили будут являться частью графа.
А почему бы не сделать по примеру CSS? CSS разбирать не совсем удобно, а свой xml было бы попроще... И делать на него ссылки? При надобности можно его внедрять в шаблон — эдакий гибрид CSS и твоего предложения? Просто использование глобального шаблона позволит менять стили всех шаблонов. Если этого не надо — внедрять в шаблон и все.
Здравствуйте, AndrewVK, Вы писали:
AVK>Да нет конечно. Ты в IE пробовал pdf открывать? И никаких полных акробатов. Попробовал сейчас кинуть ActiveX акробатовский на шарповскую форму — вроде бы тоже все работает.
Пробовал, только вот в ослика не контрол подгружается, а сам ридер как сервер автоматизации. Точно так же ведет себя и Word — а ведь у него уж точно контрола нет.
Ved>>И не понимает документов из потока, только из файла.
AVK>Опять же как тогда он доки из инета показывает? И что означает свойство src контрола?
Temporary Internet Files. Но зарекаться не буду — с контролом не работал, попробую на выходных.
получается. Тогда действительно очень хорошо было бы дополнительно сделать свой формат и самим его печатать и просматривать. А преобразования можно было бы и сторонними библиотеками выполнять. Идеально сюда мог бы вписаться еще и сервер отчетов.
