В модели данных отчета легко совместить нужды и OLAP и простого ценника.
Достаточно представить данные иерархически.
Пусть каждая строка данных отчеат содержит от 0-ля до бесконечности ПОДЧИНЕННЫХ НАБОРОВ ДАННЫХ (так сделано в одном из мощнейших генераторов Oracle Report Server).
CristalReport, или Access например, предполагают, что если и может быть подчиненный набор данных, то только один. А это крайне порою неудобно.
Предложенная организация данных одинаково хорошо подойдет как для простого "линейного" источника данных, так и для и для источника данных произвольной сложности.
Насчет XML — это обязательно?
Предлагаю использовать его КАК ОДИН ИЗ ФОРМАТОВ как для хранения макета, так и для входных данных.
Предлагаю обратить внимание на то, как работает нетовский грид — ему можно подать любой контейнер объектов, не обязательно рекордсет. Предлагаю сделать допустимым для отчета ЛЮБОЙ источник данных — от Array и ArrayList до TableSet. Рефлекшен легко позволит это сделать.На любой внешний источник данных может "навешиваться" адаптер, приводящие данные к удобному внутреннему виду.
Добрый день, vdimas, Вы писали:
V>В модели данных отчета легко совместить нужды и OLAP и простого ценника. V>Достаточно представить данные иерархически.
V>Предложенная организация данных одинаково хорошо подойдет как для простого "линейного" источника данных, так и для и для источника данных произвольной сложности.
V>Насчет XML — это обязательно? V>Предлагаю использовать его КАК ОДИН ИЗ ФОРМАТОВ как для хранения макета, так и для входных данных.
V>Предлагаю обратить внимание на то, как работает нетовский грид — ему можно подать любой контейнер объектов, не обязательно рекордсет. Предлагаю сделать допустимым для отчета ЛЮБОЙ источник данных — от Array и ArrayList до TableSet. Рефлекшен легко позволит это сделать.На любой внешний источник данных может "навешиваться" адаптер, приводящие данные к удобному внутреннему виду.
Может всё таки так:
Источник(и) данных -> XML -> ReportEngine ?
1) XML — это стандартный универсальный способ. Любой другой способ создания/хранения/передачи деревянных данных будет просто повторять возможности XML.
2) Источники данных инкапсулируют в себе правила преобразования данных в деревянную структуру и могут быть созданы независимо — OLAP->XML, DataSet->XML, Array->XML, XML->XML ( )
3) Частный случай источника данных — это его "отсутствие" , т.е. все данные генерируются клиентской программой.
V>Пусть каждая строка данных отчеат содержит от 0-ля до бесконечности ПОДЧИНЕННЫХ НАБОРОВ ДАННЫХ (так сделано в одном из мощнейших генераторов Oracle Report Server). V>CristalReport, или Access например, предполагают, что если и может быть подчиненный набор данных, то только один. А это крайне порою неудобно.
Только, имхо, не каждая строка, а только специально заданные в шаблоне.
Здравствуйте, vdimas, Вы писали:
V>В модели данных отчета легко совместить нужды и OLAP и простого ценника.
Я не уверен в том что вобще репортер должен заниматься обработкой данных.
V>Насчет XML — это обязательно?
Твои предложения по представлению нереляционных данных.
V>Предлагаю использовать его КАК ОДИН ИЗ ФОРМАТОВ как для хранения макета, так и для входных данных.
А зачем много форматов?
V>Предлагаю обратить внимание на то, как работает нетовский грид — ему можно подать любой контейнер объектов, не обязательно рекордсет.
Набор входных данных у него ограничен.
V> Предлагаю сделать допустимым для отчета ЛЮБОЙ источник данных — от Array и ArrayList до TableSet.
Любой даже DataGrid не умеет. Да и алгоритмы это усложнит весьма серьезно.
V> Рефлекшен легко позволит это сделать.На любой внешний источник данных может "навешиваться" адаптер, приводящие данные к удобному внутреннему виду.
Здравствуйте, AndrewVK, Вы писали:
V>>Предлагаю использовать его КАК ОДИН ИЗ ФОРМАТОВ как для хранения макета, так и для входных данных.
AVK>А зачем много форматов?
+1
V>>Предлагаю обратить внимание на то, как работает нетовский грид — ему можно подать любой контейнер объектов, не обязательно рекордсет.
AVK>Набор входных данных у него ограничен.
+1
V>> Предлагаю сделать допустимым для отчета ЛЮБОЙ источник данных — от Array и ArrayList до TableSet.
AVK>Любой даже DataGrid не умеет. Да и алгоритмы это усложнит весьма серьезно.
V>> Рефлекшен легко позволит это сделать.На любой внешний источник данных может "навешиваться" адаптер, приводящие данные к удобному внутреннему виду.
AVK>Это слишком сложно имхо.
Да и не надо, кому потребуется сделает конвертер. Один, распостраненный случай, можно сделать как пример.
Здравствуйте, mrhru, Вы писали:
M>Может всё таки так: M>Источник(и) данных -> XML -> ReportEngine ?
Я что-то никак не воткну, какой выигрыш дает XML. Его все-равно в DOM загнать целиком надо перед растеризацией.
M>1) XML — это стандартный универсальный способ. Любой другой способ создания/хранения/передачи деревянных данных будет просто повторять возможности XML.
Ну да, берем приличное количество бинарных данных, переводим их в XML, а затем engine генератора отчетов опять это в бинарный вид DOM переводит, путем распарсивания XML. Что, скоро пентиум 10Гц выходит? Можно тяп-ляп приложения писать?
M>2) Источники данных инкапсулируют в себе правила преобразования данных в деревянную структуру и могут быть созданы независимо — OLAP->XML, DataSet->XML, Array->XML, XML->XML ( )
XML — повторю для особо упорствующих. XML-это не конечные данные, это даже не исходные данные для растеризатора отчета. Это исходные данные для XML-parser-а.
M>3) Частный случай источника данных — это его "отсутствие" , т.е. все данные генерируются клиентской программой.
Ради бога. Сгенери структуру в памяти, и подай как источник данных для отчета! Об этом я и говорю.
V>>Пусть каждая строка данных отчеат содержит от 0-ля до бесконечности ПОДЧИНЕННЫХ НАБОРОВ ДАННЫХ (так сделано в одном из мощнейших генераторов Oracle Report Server). V>>CristalReport, или Access например, предполагают, что если и может быть подчиненный набор данных, то только один. А это крайне порою неудобно.
M> Только, имхо, не каждая строка, а только специально заданные в шаблоне.
Это стеб, или в следующий раз надо жевать до самого дна? Мы обсуждаем возможности, вот я и говорю, путь каждая строка содержит от 0-ля до бесконечности подчиненных наборов данных. Количество этих наборов в каждом конкретном случае, разумеется (!!!), задается при проектировании шаблона конкретного отчета. Но ОЧЕНЬ желательно иметь такую возможность, т.к. генераторы отчетов, типа MS Access ПРИНЦИПИАЛЬНО не позволяют проектировать многие полезные разновидности представления информации.
Здравствуйте, AndrewVK, Вы писали:
V>>В модели данных отчета легко совместить нужды и OLAP и простого ценника.
AVK>Я не уверен в том что вобще репортер должен заниматься обработкой данных.
Практически в ЛЮБОМ отчете применяются групповые операции. Большая часть печатаемых в мире отчетов предназначена именно для средств анализа. И именно из OLAP беруться данные.
V>>Насчет XML — это обязательно? AVK>Твои предложения по представлению нереляционных данных.
Иерархическая сруктура в памяти. Повторюсь: пусть каждая строка данных может содержать от 0-ля до бесконечности подчиненных наборов данных.
V>>Предлагаю использовать его КАК ОДИН ИЗ ФОРМАТОВ как для хранения макета, так и для входных данных. AVK>А зачем много форматов?
Затем, что много ситуаций. Но как минимум 2 формата: бинарный и XML поддерживать надо. (Это все для МАКЕТА, не для источника данных)
V>>Предлагаю обратить внимание на то, как работает нетовский грид — ему можно подать любой контейнер объектов, не обязательно рекордсет.
AVK>Набор входных данных у него ограничен.
Набор входных данных у него практически неограничен. ЛЮБОЙ сложный тип (не integer и т.д.) можно подать в качестве источника данных (если этот тип регулярен). Или ты имеешь ввиду ограниченные возможности ВИЗУАЛЬНОГО редактора свойств?
V>> Предлагаю сделать допустимым для отчета ЛЮБОЙ источник данных — от Array и ArrayList до TableSet. AVK>Любой даже DataGrid не умеет. Да и алгоритмы это усложнит весьма серьезно.
Это весьма серьезно упростит алгоритмы, двоечник. IEnumerable, IDictionary, IDataRecord и т.д.
V>> Рефлекшен легко позволит это сделать.На любой внешний источник данных может "навешиваться" адаптер, приводящие данные к удобному внутреннему виду.
AVK>Это слишком сложно имхо.
А это даже еще проще, чем XML, т.к. reflection-данные тоже представлены ввиде иерархического набора, весьма удобного для оперирования ими. Нет там ничего сложного, на этот раз микрософт выпустила продукт, который и старшекласники с легкостью осваивают.
> Практически в ЛЮБОМ отчете применяются групповые операции. Большая часть >печатаемых в мире отчетов предназначена именно для средств анализа. И именно из OLAP беруться данные.
Нужно отделить обработку и анализ данных и собственно средства форматирования и печати. Сначала сделать инструмент для печати, а потом — для анализа и группировки данных, который будет выступать клиентом.
Здравствуйте, vdimas, Вы писали:
M>>Может всё таки так: M>>Источник(и) данных -> XML -> ReportEngine ?
V>Я что-то никак не воткну, какой выигрыш дает XML. Его все-равно в DOM загнать целиком надо перед растеризацией.
M>>1) XML — это стандартный универсальный способ. Любой другой способ создания/хранения/передачи деревянных данных будет просто повторять возможности XML. V>Ну да, берем приличное количество бинарных данных, переводим их в XML, а затем engine генератора отчетов опять это в бинарный вид DOM переводит, путем распарсивания XML. Что, скоро пентиум 10Гц выходит? Можно тяп-ляп приложения писать?
"Это стеб, или в следующий раз надо жевать до самого дна?" (с)
Ну конечно, пока ещё Р 100ГГц не вышел, передавать данные между компонентами программы не следует в чистом XML.
M>>2) Источники данных инкапсулируют в себе правила преобразования данных в деревянную структуру и могут быть созданы независимо — OLAP->XML, DataSet->XML, Array->XML, XML->XML ( ) V>XML — повторю для особо упорствующих. XML-это не конечные данные, это даже не исходные данные для растеризатора отчета. Это исходные данные для XML-parser-а.
M>>3) Частный случай источника данных — это его "отсутствие" , т.е. все данные генерируются клиентской программой. V>Ради бога. Сгенери структуру в памяти, и подай как источник данных для отчета! Об этом я и говорю.
"Структура в памяти" — это что-то вроде XML DOM?
V>>>Пусть каждая строка данных отчеат содержит от 0-ля до бесконечности ПОДЧИНЕННЫХ НАБОРОВ ДАННЫХ (так сделано в одном из мощнейших генераторов Oracle Report Server). V>>>CristalReport, или Access например, предполагают, что если и может быть подчиненный набор данных, то только один. А это крайне порою неудобно.
Так с этим совершенно согласен. (И просто разворачивать флейм, придираясь к терминам, не было никакого желания).
И сам раньше сталкивался с ограничениями разных генераторов. Особенно "понравилось" у некоторых ГО — это то, что данные они могут выбирать только из датасетов. А когда требуется шаг влево-вправо — то — либо это невозможно, либо делается с помощью всяческих подпорок-костылей.
M>> Только, имхо, не каждая строка, а только специально заданные в шаблоне. V>Это стеб, или в следующий раз надо жевать до самого дна? Мы обсуждаем возможности, вот я и говорю, путь каждая строка содержит от 0-ля до бесконечности подчиненных наборов данных. Количество этих наборов в каждом конкретном случае, разумеется (!!!), задается при проектировании шаблона конкретного отчета. Но ОЧЕНЬ желательно иметь такую возможность, т.к. генераторы отчетов, типа MS Access ПРИНЦИПИАЛЬНО не позволяют проектировать многие полезные разновидности представления информации.
Опять же согласен. Именно подобное я здесь и написал раньше.
Здравствуйте, vdimas, Вы писали:
V>>>Пусть каждая строка данных отчеат содержит от 0-ля до бесконечности ПОДЧИНЕННЫХ НАБОРОВ ДАННЫХ (так сделано в одном из мощнейших генераторов Oracle Report Server). V>>>CristalReport, или Access например, предполагают, что если и может быть подчиненный набор данных, то только один. А это крайне порою неудобно.
Вот такое предложение:
(В основном взято из FO)
— Блок — прямоугольная область с кучей атрибутов (рамки, фон etc.) Возможно именованая.
— Блок может содержать список блоков — вертикальный или горизонтальный.
— либо в блоке нет субблоков, тогда он может содержать текст, изображение... Назовём его ячейкой.
— Текст ячейки может содержать конструкцию [<Name>], которая при генерации отчёта будет заменена на значение (что-то вроде <Name>Value</Name> в данных для отчёта)
— При генерации отчёта, при выводе некоторого блока, те его субблоки, не имеющие имени, будут выведены сразу с блоком.
— Именованные субблоки выводятся только наличии в данных специальных указаний. Таким образом, например, можно подготовить для вывода несколько похожих строк и выводить их в зависимости от каких-либо условий.
Типа:
<GoodClientRow>...</GoodClientRow>
<GoodClientRow>...</GoodClientRow> <BadClientRow>...</BadClientRow>
<GoodClientRow>...</GoodClientRow>
Это позволит избавится от необходимости передавать форматирование элементов отчёта в самих данных.
Здравствуйте, mrhru, Вы писали:
M>Здравствуйте, vdimas, Вы писали:
V>>>>Пусть каждая строка данных отчеат содержит от 0-ля до бесконечности ПОДЧИНЕННЫХ НАБОРОВ ДАННЫХ (так сделано в одном из мощнейших генераторов Oracle Report Server). V>>>>CristalReport, или Access например, предполагают, что если и может быть подчиненный набор данных, то только один. А это крайне порою неудобно.
Еще бы поддержку динамических датасетов включить — а ля Cross-Table
M>Вот такое предложение:
M>(В основном взято из FO) M>- Блок — прямоугольная область с кучей атрибутов (рамки, фон etc.) Возможно именованая. M>- Блок может содержать список блоков — вертикальный или горизонтальный. M> — либо в блоке нет субблоков, тогда он может содержать текст, изображение... Назовём его ячейкой. M>- Текст ячейки может содержать конструкцию [<Name>], которая при генерации отчёта будет заменена на значение (что-то вроде <Name>Value</Name> в данных для отчёта)
Можно например уточнить:
Block = [Header(1)]+[Footer(1)]+DynamicData — (то что читается из рекордсета циклически)
DynamicData = [Header(1)]+[Footer(1)]+Item(*)
Item = Text(и все остальное)|Block;
M>- При генерации отчёта, при выводе некоторого блока, те его субблоки, не имеющие имени, будут выведены сразу с блоком. M>- Именованные субблоки выводятся только наличии в данных специальных указаний. Таким образом, например, можно подготовить для вывода несколько похожих строк и выводить их в зависимости от каких-либо условий. M>Это позволит избавится от необходимости передавать форматирование элементов отчёта в самих данных.
Это плохое архитектурное решение — лучше просто привязать к блоку скрипт или даже несколько скриптов на которые можно возложить следующие задачи:
1. Формирование стиля блока
2. Принятие решений на вывод/не вывод блока
3. Подсчет статистики
4. ...
M>Ы?
Зы
Здравствуйте, vdimas, Вы писали:
AVK>>Я не уверен в том что вобще репортер должен заниматься обработкой данных.
V>Практически в ЛЮБОМ отчете применяются групповые операции. Большая часть печатаемых в мире отчетов предназначена именно для средств анализа. И именно из OLAP беруться данные.
Да ради бога. Мне непонятно другое — почему этим должен заниматься репортер? Если нужны средства подготовки данных значит надо писать средства подготовки данных.
AVK>>Твои предложения по представлению нереляционных данных. V>Иерархическая сруктура в памяти.
А XML DOM что, не иерархическая? Зачем велосипеды то изобретать?
AVK>>А зачем много форматов? V>Затем, что много ситуаций. Но как минимум 2 формата: бинарный и XML поддерживать надо.
Зачем? чтобы писать две версии генератора для разных форматов?
V>(Это все для МАКЕТА, не для источника данных)
Вот это особенно и изумляет. Уж макет то зачем многоформатный делать?
AVK>>Набор входных данных у него ограничен. V>Набор входных данных у него практически неограничен.
Открой документацию и почитай, там список приведен.
V>ЛЮБОЙ сложный тип (не integer и т.д.) можно подать в качестве источника данных (если этот тип регулярен).
Не любой, только IList.
V>Или ты имеешь ввиду ограниченные возможности ВИЗУАЛЬНОГО редактора свойств?
Кто это такой?
AVK>>Любой даже DataGrid не умеет. Да и алгоритмы это усложнит весьма серьезно. V>Это весьма серьезно упростит алгоритмы, двоечник.
Ты это, поаккуратнее.
V>IEnumerable, IDictionary, IDataRecord и т.д.
И т.д. там мало совсем.
V>>> Рефлекшен легко позволит это сделать.На любой внешний источник данных может "навешиваться" адаптер, приводящие данные к удобному внутреннему виду. AVK>>Это слишком сложно имхо. V>А это даже еще проще, чем XML, т.к. reflection-данные тоже представлены ввиде иерархического набора, весьма удобного для оперирования ими. Нет там ничего сложного, на этот раз микрософт выпустила продукт, который и старшекласники с легкостью осваивают.
Не рассказывай мне что такое дотнет, я это хорошо представляю. Я вижу другое — море рукописных алгоритмов, которых можно избежать.
Здравствуйте, vdimas, Вы писали:
V>Я что-то никак не воткну, какой выигрыш дает XML. Его все-равно в DOM загнать целиком надо перед растеризацией.
Так, входной xml никто растеризовать не собирается. На него надо еще наложить шаблон, преобразовывающий его в набор примитивов генератора, затем из набора примитивов получить FO или еще какой графический формат и только затем уже растеризовать.
M>> Только, имхо, не каждая строка, а только специально заданные в шаблоне. V>Это стеб, или в следующий раз надо жевать до самого дна? Мы обсуждаем возможности, вот я и говорю, путь каждая строка содержит от 0-ля до бесконечности подчиненных наборов данных. Количество этих наборов в каждом конкретном случае, разумеется (!!!), задается при проектировании шаблона конкретного отчета.
Ты только не говоришь чем это лучше стандартизованного XML. Да, рекомендую еще задуматься о языке выбора из входных данных подмножества для конкретного примитива шаблона.
V>Но ОЧЕНЬ желательно иметь такую возможность, т.к. генераторы отчетов, типа MS Access ПРИНЦИПИАЛЬНО не позволяют проектировать многие полезные разновидности представления информации.
О структуре примитивов никто и не говорит. Более того, скорее всего ты сам сможешь написать примитив, реализующий интересующую тебя модель.
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Твои предложения по представлению нереляционных данных. V>>Иерархическая сруктура в памяти.
AVK>А XML DOM что, не иерархическая? Зачем велосипеды то изобретать?
А затем, что бы можно было подавать произвольную структуру в качестве источника данных. Если говоришь, что знаешь НЕТ, то напомню, что биндинг можно выполнять к произвольным публичным свойствам. И для этого не надо писать МОРЕ РУКОПИСНОГО ТЕКСТА, т.к. все средства для поддержки биндига уже есть. Указваешь просто объект и имя свойства. Для НЕТ не существует разницы, прибиндился ты к рекорду или к любой другой структуре. Для тебя это будет один и тот же код — одна строчка. Имена свойств (в случае рекордсета — это имена полей) беруться из шаблона.
Предположим, что мы имеем отчет, который выводит простой список телефонов. В нем всего 2 поля: (FullName, Phone).
Так вот, ты НЕ МЕНЯЯ НИЧЕГО можешь подать туда рекордсет из базы, или же свою структуру:
rpt.DataSource=new PhoneListItem[] { new PhoneListItem("Вася", "11-11-11"), new PhoneListItem("Петя", "22-22-22") };
Это, конечно, вырожденный пример, но показывает суть. Мы (приложение) сможем формировать произвольную структуру из произвольных классов в памяти, главное чтобы имена полей на отчете соответствовали публичным свойствам объектов в этой структуре (впрочем, это верно и для источника — рекордсета).
AVK>>>А зачем много форматов? V>>Затем, что много ситуаций. Но как минимум 2 формата: бинарный и XML поддерживать надо. AVK>Зачем? чтобы писать две версии генератора для разных форматов?
Ну, ЧУДАК ЧЕЛОВЕК!!!! Это мы .NET знаем?
Да в одной строке сериализуем модель отчета как XML, а в другой — как Binary!!! И считываем аналогично — по одной строке на формат — .NET все сама делает.
V>>IEnumerable, IDictionary, IDataRecord и т.д. AVK>И т.д. там мало совсем.
а мне только IEnumerable достаточно!!! (хотя, можно подняться на "ступенечку", и ограничиться ICollection).
V>>>> Рефлекшен легко позволит это сделать.На любой внешний источник данных может "навешиваться" адаптер, приводящие данные к удобному внутреннему виду. AVK>>>Это слишком сложно имхо.
Это биндинг, это одна строчка.
AVK>Не рассказывай мне что такое дотнет, я это хорошо представляю. Я вижу другое — море рукописных алгоритмов, которых можно избежать.
Мы их уже избежали.
Здравствуйте, vdimas, Вы писали:
AVK>>А XML DOM что, не иерархическая? Зачем велосипеды то изобретать? V>А затем, что бы можно было подавать произвольную структуру в качестве источника данных.
Что то я видимо не понимаю. Произвольную структуру передавать нельзя вне зависимости от формата, потому что для любой структуры нужна поддержка со стороны обрабатывающего кода. И самопальные деревья ничуть не лучше в этом плане XML.
V> Если говоришь, что знаешь НЕТ, то напомню, что биндинг можно выполнять к произвольным публичным свойствам.
Ну и что? Ну какая разница как будет происходить биндинг — к метаданнным классов или к тегам XML?
V> И для этого не надо писать МОРЕ РУКОПИСНОГО ТЕКСТА,
А почему ты решил что подобное в случае XML невозможно?
V> т.к. все средства для поддержки биндига уже есть.
Биндинг предназначен совсем для другого.
V>Это, конечно, вырожденный пример, но показывает суть. Мы (приложение) сможем формировать произвольную структуру из произвольных классов в памяти, главное чтобы имена полей на отчете соответствовали публичным свойствам объектов в этой структуре (впрочем, это верно и для источника — рекордсета).
Напомниаю — отчет это немножко другое. Попробуй при помощи замечательного биндинга прибиндить дерево ввиде плоской структуры со ссылками на родителя. Биндинг хорош при отображении плоских списков, связанных между собой. А вот структуры послежнее вызывают серьезный гемморой. Для интерфейса это еще терпимо, а вот для отчетов никуда не годится, поскольку структура представления может кардинально отличаться от структуры данных. Одни и те же данные могут повторяться многократно, порядок отображения меняться, иерархические структуры перестраиваться. Прелесть биндинга не в том что ты описал, много ума пользоваться рефлекшеном не надо, прелесть биндинга в другой фишке, в BindingContext, а вот для отчетов эта фишка бесполезна.
AVK>>Зачем? чтобы писать две версии генератора для разных форматов? V>Ну, ЧУДАК ЧЕЛОВЕК!!!! Это мы .NET знаем?
Попрошу все таки не учить меня дотнету, со стороны выглядит смешно.
V>Да в одной строке сериализуем модель отчета как XML, а в другой — как Binary!!! И считываем аналогично — по одной строке на формат — .NET все сама делает.
Никто и ничего сам делать не будет и сериализация тут не при чем. Механика наложения шаблона на данные должна либо знать семантику входных данных, либо иметь средства их описания.
AVK>>Не рассказывай мне что такое дотнет, я это хорошо представляю. Я вижу другое — море рукописных алгоритмов, которых можно избежать. V>Мы их уже избежали.
Андрей, ты меня конечно извини, но у меня ощущение, что я беседую с глухим. Пишу последний раз, потому что уже начинаем кружиться по кругу.
AVK>Что то я видимо не понимаю. Произвольную структуру передавать нельзя вне зависимости от формата, потому что для любой структуры нужна поддержка со стороны обрабатывающего кода. И самопальные деревья ничуть не лучше в этом плане XML.
Я предлагаю использовать встроенные средства библиотеки mscorlib для доступа к полям входного источника данных. Есть два побочных эффекта от моего предложения:
1. Отсутствие необходимости ручками писать тонну кода, реализующего механизм наложения данных на визуальные элементы.
2. Мы имеем возможность подавать практически произвольные объекты в качестве источников данных, XML — лишь один из частных случаев.
AVK>Ну и что? Ну какая разница как будет происходить биндинг — к метаданнным классов или к тегам XML?
Не к тегам, к модели DOM (мы ведь рассматриваем ВНУТРЕННЮЮ модель данных), что ничуть не лучше, чем к любой другой структуре (в подавляющем большинстве случаев — не такой "прожорливой")
AVK>А почему ты решил что подобное в случае XML невозможно?
уже ответил...
V>> т.к. все средства для поддержки биндига уже есть. AVK>Биндинг предназначен совсем для другого.
Он именно для этого предназначен. И берет свои корни от COM. Bind — это связывание. В .NET binding происходит по имени свойства, что нам и требуется!!!
AVK>Напомниаю — отчет это немножко другое. Попробуй при помощи замечательного биндинга прибиндить дерево ввиде плоской структуры со ссылками на родителя. Биндинг хорош при отображении плоских списков, связанных между собой.
Все, не могу... Отсылаю к модели DOM твоего же XML. Узлы XML-документа не содержаться в одной плоской таблице.
Древовидная структура достигается за счет включения элементами дерева (узлами), списка child-источников данных (!!! смотрим список имплементируемых интерфейсов для классов XmlNode и XmlnodeList), которые в свою очередь могут включать и т.д...
AVK>поскольку структура представления может кардинально отличаться от структуры данных. Одни и те же данные могут повторяться многократно, порядок отображения меняться, иерархические структуры перестраиваться.
Мы можем только группировать по некоторым полям, т.е. усложнять структуру (что элементарно), но никогда не наоборот.
AVK>Прелесть биндинга не в том что ты описал, много ума пользоваться рефлекшеном не надо, прелесть биндинга в другой фишке, в BindingContext, а вот для отчетов эта фишка бесполезна.
Да? BindingContext служит для того, чем и обзывается — для группировки Binding-ов. Я бы использовал свой BindingContext на каждый источник данных, для изоляции одноименных полей в этих источниках.
AVK>Никто и ничего сам делать не будет и сериализация тут не при чем. Механика наложения шаблона на данные должна либо знать семантику входных данных, либо иметь средства их описания.
Структура входных данных задается при проектировании шаблона. После этого, подаваемые данные могут либо соответствовать этой структуре, либо нет.
(используешь иерархические рекордсеты? А MS DataShape Provider?)
Скажу, почему я категорически против использования XML как источника данных. Только из-за невероятной прожорливости ресурсов. Распечатать обычный прайс-лист для оптовой фирсы из 15 тыс строк — машина однозначно сдохнет в таких условиях. Хочу подавать всякие Record-ы, Tables или просто коллекции структур, созданных в памяти. (Напр. мы рассчитали довольно сложный отчет, который одним запросом к базе ну ни как не выполнишь, и потом просто подаем свою структуру как источник данных, главное, чтобы IEnumerable имплементилось, напр. new object[]{singleMainRowReportComplexData}
Никто не мешает использовать XML как частный случай.
Так что, о чем, собственно, спор?
Здравствуйте, vdimas, Вы писали:
V>Андрей, ты меня конечно извини, но у меня ощущение, что я беседую с глухим.
У меня тоже. Ты почему то упорно не желаешь понять то, что что такое датабиндинг я не знаю и пытаешься мне про него рассказать. Ты попробуй исходить из предположения что таки я прекрасно представляю что это такое и тем не менее посчитал его неподходящим вариантом.
V> Есть два побочных эффекта от моего предложения: V>1. Отсутствие необходимости ручками писать тонну кода, реализующего механизм наложения данных на визуальные элементы.
Пока что я вижу в точности обратную ситуацию — вместо использования XSLT придется использовать в разы менее гибкий датабиндинг и реалзовывать его поддержку как это сделано в датагриде. Декомпильни датагрид и полубуйся на объем кода, связанного с поддержкой датабиндинга. А то что для текстбокса этой поддержки нет невелика заслуга, отчеты не только из примитивных текстбоксов состоят. Еще раз предлагаю подумать как ты без написания специального кода выведешь иерархическую структуру в одной проской таблице.
V>2. Мы имеем возможность подавать практически произвольные объекты в качестве источников данных, XML — лишь один из частных случаев.
А если клиент не дотнетный? А как ты такие данные передашь по сети на репорт-сервер? Каким образом ты будешь подключать внешние данные от других систем, не имеющих для них дотнетных классов-оберток? Ответь на эти вопросы.
V>Не к тегам, к модели DOM
Кто сказал что DOM? DOM нужна только если ты хочешь ис пользовательского кода что то подправить. А вобще речь шла об XML, а не о DOM.
V>(мы ведь рассматриваем ВНУТРЕННЮЮ модель данных), что ничуть не лучше, чем к любой другой структуре (в подавляющем большинстве случаев — не такой "прожорливой")
Проблема только в том что такая структура может просто не понадобиться. Например если репорты генерит отдельный сервер то клиенту вобще ничего в память поднимать не придется.
AVK>>Биндинг предназначен совсем для другого. V>Он именно для этого предназначен. И берет свои корни от COM. Bind — это связывание. В .NET binding происходит по имени свойства, что нам и требуется!!!
Вот именно что связывание. В качестве альтернативы я предлагал XPath — не менее удобное средство в случае отчетов. А вот наложение шаблона в случае самопальных структур тебе придется писать самому.
V>Все, не могу... Отсылаю к модели DOM твоего же XML. Узлы XML-документа не содержаться в одной плоской таблице. V>Древовидная структура достигается за счет включения элементами дерева (узлами), списка child-источников данных (!!! смотрим список имплементируемых интерфейсов для классов XmlNode и XmlnodeList), которые в свою очередь могут включать и т.д...
Не стоит зацикливаться на реализации. К XML возможны запросы на языке XPath, который работает именно с иерархией. То что в случае биндинга можно дописать преобразование и таки получить иерархию я не спорю. Вот только я не хочу дописывать руками то что уже реализовано в случае xml.
V>Мы можем только группировать по некоторым полям, т.е. усложнять структуру (что элементарно), но никогда не наоборот.
Ну а у меня как то пошире представление о структуре отчетов сложилось.
AVK>>Прелесть биндинга не в том что ты описал, много ума пользоваться рефлекшеном не надо, прелесть биндинга в другой фишке, в BindingContext, а вот для отчетов эта фишка бесполезна. V>Да? BindingContext служит для того, чем и обзывается — для группировки Binding-ов. Я бы использовал свой BindingContext на каждый источник данных, для изоляции одноименных полей в этих источниках.
Вот уж точно не хочешь оторваться от того что знаешь. Зачем отчетам контекст биндинга? Отчет структура статическая, и BindingManager, ради которого этот контекст придумывался, отчету как собаке пятая нога.
V>Структура входных данных задается при проектировании шаблона.
В каком виде? Вот в случае XSLT все понятно — XPAth. А вот в случае датабиндинга что? Самопальный язык описания сочинять?
V>Скажу, почему я категорически против использования XML как источника данных. Только из-за невероятной прожорливости ресурсов.
Датасеты не менее прожорливы. А еще есть такая штука как XmlDataDocument
V>Никто не мешает использовать XML как частный случай. V>Так что, о чем, собственно, спор?
Здравствуйте, AndrewVK, Вы писали:
AVK>Вот именно что связывание. В качестве альтернативы я предлагал XPath — не менее удобное средство в случае отчетов. А вот наложение шаблона в случае самопальных структур тебе придется писать самому.
А я и не против сам это написать. Давно мечтал иметь генератор шаблонов для клиентской стороны, для которого я мог бы молниеносно в памяти формировать структурки и подавать их как источник данных. И никакой внутренний язык для описания внешнего отчета не нужен — я предполагал использование визуального редактора типа MSACCESS или CristallReports, т.е. визуально накидываем группы, бросаем визуальные элементы на разделы отчета, в этих визуальных элементах прописываем ИМЯ поля — источника данных. Я думаю, что подобный продукт бесплатно, на одном энтузиазме можно сделать только в среде .NET (из-за множества фишечек, резко облегчающих жизнь). Более того, наподобие того же MSACCESS я предполагал возможность снабжать подобный отчет макро-языком, на основе того же VSA, работающего по событиям растеризации (напр. можно будет в зависимости от довольно сложных, алгоритмически вычисляемых условий, "играть" форматированием полей, секций, строк таблиц).
А что предлагаешь ты? XLT? Для сервера отчетов? А на кой ляд нам тогда .NET? Это и на С++ не хуже делается, да еще и РОВНО НА ПОРЯДОК быстрее работает. Где здесь .NET? Для XML под С++ есть ВСЕ ЧТО УГОДНО, и гораздо больше, чем под .NET.
Если ты действительно .NET знаешь, так чего тогда бояться некоторой работки? Тем более, что в награду получим практически все, что пожелаем.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, AndrewVK, Вы писали:
AVK>>Вот именно что связывание. В качестве альтернативы я предлагал XPath — не менее удобное средство в случае отчетов. А вот наложение шаблона в случае самопальных структур тебе придется писать самому.
V>А я и не против сам это написать. Давно мечтал иметь генератор шаблонов для клиентской стороны, для которого я мог бы молниеносно в памяти формировать структурки и подавать их как источник данных. И никакой внутренний язык для описания внешнего отчета не нужен — я предполагал использование визуального редактора типа MSACCESS или CristallReports, т.е. визуально накидываем группы, бросаем визуальные элементы на разделы отчета, в этих визуальных элементах прописываем ИМЯ поля — источника данных.
А я думал как раз так и будет, тю.. Ведь после наложения шаблона получается набор примитивов, фактически универсальный расширяемый язык отоборажения. Если примитив подразумевает какое-то поведение его можно отобразить в дизайнере, а потом в выходном файле это сделает сам формат.
V>Я думаю, что подобный продукт бесплатно, на одном энтузиазме можно сделать только в среде .NET (из-за множества фишечек, резко облегчающих жизнь). Более того, наподобие того же MSACCESS я предполагал возможность снабжать подобный отчет макро-языком, на основе того же VSA, работающего по событиям растеризации (напр. можно будет в зависимости от довольно сложных, алгоритмически вычисляемых условий, "играть" форматированием полей, секций, строк таблиц).
На выходе-то файл выбранного формата, если формат это все поддерживает, то и в чем проблема? К тому же, кто мешает, получать HTML (к примеру) и пристегивать заранее написанные скрипты (behaviors). XSLT это же правила преобразования, а внешний вид это на примитивах держится.
V>А что предлагаешь ты? XLT? Для сервера отчетов? А на кой ляд нам тогда .NET? Это и на С++ не хуже делается, да еще и РОВНО НА ПОРЯДОК быстрее работает. Где здесь .NET? Для XML под С++ есть ВСЕ ЧТО УГОДНО, и гораздо больше, чем под .NET.
Net элегантнее.
V>Если ты действительно .NET знаешь, так чего тогда бояться некоторой работки? Тем более, что в награду получим практически все, что пожелаем.
Имхо получиться все, практические работоспособное.
Здравствуйте, vdimas, Вы писали:
AVK>>Вот именно что связывание. В качестве альтернативы я предлагал XPath — не менее удобное средство в случае отчетов. А вот наложение шаблона в случае самопальных структур тебе придется писать самому.
V>А я и не против сам это написать.
Зато я против.
V>Давно мечтал иметь генератор шаблонов для клиентской стороны, для которого я мог бы молниеносно в памяти формировать структурки и подавать их как источник данных. И никакой внутренний язык для описания внешнего отчета не нужен — я предполагал использование визуального редактора типа MSACCESS или CristallReports, т.е. визуально накидываем группы, бросаем визуальные элементы на разделы отчета, в этих визуальных элементах прописываем ИМЯ поля — источника данных.
В 1С твоя мечта давно осуществилась .
V>А что предлагаешь ты? XLT? Для сервера отчетов? А на кой ляд нам тогда .NET?
А что, в .NET нет XSLT-процессора? Или ты думаешь что вся сложность только в механике наложения шаблона? В любом случае — изначальная предпосылка была генератор отчета для .NET. Писать на чем то другом и потом воевать с интеропом несколько странно, не находишь?
V>да еще и РОВНО НА ПОРЯДОК быстрее работает.
Ровно? И ни в коем случае не на полтора? Мерял?
V>Если ты действительно .NET знаешь, так чего тогда бояться некоторой работки?
Потому что во мне давно угас пыл изобретать велосипеды и если я что то пишу с нуля мне надо точно знать что без этого не обойтись.
V> Тем более, что в награду получим практически все, что пожелаем.
Здравствуйте, AndrewVK, Вы писали:
V>>Скажу, почему я категорически против использования XML как источника данных. Только из-за невероятной прожорливости ресурсов. AVK>Датасеты не менее прожорливы. А еще есть такая штука как XmlDataDocument
V>>Никто не мешает использовать XML как частный случай. V>>Так что, о чем, собственно, спор? AVK>О том что в твоем варианте работы намного больше.
Если не забывать, что проект модульный, то почему не сделать базовый модуль получения шаблона(и данных) из XML, а потом по мере надобности можно дописать заполнение данных и из других источников, т.к. действительно, желательно учитывать возможность заполнения шаблона данными из памяти и т.д., т.к. иной раз требования к серверу отчетов достаточно высокие. Так, в конце финансового года компании надо печатать много, очень много, как всегда — на вчера.
Здравствуйте, 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 предлагается написать.
)
Только, имхо, не каждая строка, а только специально заданные в шаблоне.
Что, скоро пентиум 10Гц выходит? Можно тяп-ляп приложения писать?
