Здравствуйте, AndrewVK, Вы писали:
Андрей, ты меня конечно извини, но у меня ощущение, что я беседую с глухим. Пишу последний раз, потому что уже начинаем кружиться по кругу.
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 как частный случай.
Так что, о чем, собственно, спор?
