Здравствуйте, Ved, Вы писали:
Ved>Если не забывать, что проект модульный, то почему не сделать базовый модуль получения шаблона(и данных) из XML, а потом по мере надобности можно дописать заполнение данных и из других источников, т.к. действительно, желательно учитывать возможность заполнения шаблона данными из памяти и т.д., т.к. иной раз требования к серверу отчетов достаточно высокие.
Потому что в качестве средства наложения шаблонов предполагается использовать XSLT. Значит все данные в ином формате все равно надо будет преобразовать в xml.
Здравствуйте, AndrewVK, Вы писали:
AVK>Потому что в качестве средства наложения шаблонов предполагается использовать XSLT. Значит все данные в ином формате все равно надо будет преобразовать в xml.
Ок. А как предлагается сделать просмотр отчета пользователем? Как предлагалось, написав рендер xsl:fo-представления? Печать тоже должна реализовываться средствами движка, а не сторонних приложений.
Здравствуйте, Ved, Вы писали:
Ved>Здравствуйте, AndrewVK, Вы писали:
AVK>>Потому что в качестве средства наложения шаблонов предполагается использовать XSLT. Значит все данные в ином формате все равно надо будет преобразовать в xml. Ved>Ок. А как предлагается сделать просмотр отчета пользователем? Как предлагалось, написав рендер xsl:fo-представления? Печать тоже должна реализовываться средствами движка, а не сторонних приложений.
Печать и визуализацию вообще пока предлагается отложить и не обсуждать.
Считается, что выходом генератора является FO. И все.
Здравствуйте, TK, Вы писали:
TK>Ну, как таковое — это не обязательно. Достаточно иметь соответствующего провайдера custom data => XPathNavigator с нужной схемой.
Ну в общем да, но запросы к навигатору идут на XPath, а реализовывать его парсер и экзекьютор что то у меня желания нет.
Здравствуйте, bizhan, Вы писали:
B>Печать и визуализацию вообще пока предлагается отложить и не обсуждать. B>Считается, что выходом генератора является FO. И все.
А дальше? Если и все, то это будет уже не генератор отчетов, а генератор FO.
Полноценным и востребованным это все будет только при наличии возможности предпросмотра и печати, а также при наличии дизайнера отчетов. Иначе, как на мой взгляд, этот проект можно закрыть. Да, конечно, всему свое время (в смысле очередности написания), но по-моему, пока что обсуждается архитектура, и в ней надо сразу закладывать все то, что хотелось бы видеть в итоге. Пока что я вижу в ней как основное
1) Модульность архитектуры и графических примитивов, наличие сервера отчетов.
2) Генерация отчетов через XSL:FO с использованием в т.ч. и пользовательских XSLT-шек.
3) Наличие просмотра, печати, дизайнера.
4) Высокая скорость работы - т.к. пусть даже это будет супер-пупер генератор,
но который будет тормозить даже при простейшем отчете, - то грош ему цена.
5) Возможность динамической генерации отчетов.
Здравствуйте, AndrewVK, Вы писали:
TK>>Ну, как таковое — это не обязательно. Достаточно иметь соответствующего провайдера custom data => XPathNavigator с нужной схемой.
AVK>Ну в общем да, но запросы к навигатору идут на XPath, а реализовывать его парсер и экзекьютор что то у меня желания нет.
А это не обязательно Достаточно реализовать только навигацию. а для Execute/Matches есть стандартная реализация. Естественно, что это не так оптимально, как могло-бы быть для родного источника данных...
Так-что можно смело декларировать использование XPathNavigator как основного провайдера данных. а там, кто как хочет — хочешь готовь свои данные в XML, накладывай на них стиль для перехода к нужной схеме, хочешь обращайся на прямую к SQL базе данных и т.п.
А особые извращенцы — могут делать собственные реализации Execute|Match для трансляции частей XPath в SQL и т.п.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Так-что можно смело декларировать использование XPathNavigator как основного провайдера данных. а там, кто как хочет — хочешь готовь свои данные в XML, накладывай на них стиль для перехода к нужной схеме, хочешь обращайся на прямую к SQL базе данных и т.п.
А нужная схема в рамках RSDN Report — это что и о чем?
А точнее — кто про нее будет знать? В каком месте генератора отчетов она будет прописана?
Пока, на сколько я понял из обсуждения, структура исходного XML произвольная. И про нее знает только
шаблон (xslt), но не генератор. И, фактически, никакой нужной съемы и нет.
Здравствуйте, TK, Вы писали:
TK>А это не обязательно Достаточно реализовать только навигацию. а для Execute/Matches есть стандартная реализация. Естественно, что это не так оптимально, как могло-бы быть для родного источника данных...
Ну то есть оптимизируем, но в результате приходим к менее оптимальному варианту
TK>Так-что можно смело декларировать использование XPathNavigator как основного провайдера данных.
В принципе можно. Это ничего не изменит.
TK>А особые извращенцы — могут делать собственные реализации Execute|Match для трансляции частей XPath в SQL и т.п.
ЕК>Печать и визуализацию вообще пока предлагается отложить и не обсуждать. ЕК>Считается, что выходом генератора является FO. И все.
ЕК>Я, может, немного подотстал от обсуждения. Подскажите, что такое FO?
Вот тут можно ознакомиться. Только я так понял он на яве для апача, порт в .Net предлагается написать.
