Здравствуйте, 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>Так что, о чем, собственно, спор?

О том что в твоем варианте работы намного больше.