Офонареть. Silverlight не умеет DataTable.

И что прикажете подсовывать в качестве сорса DataGrid-у????

Здравствуйте, Аноним, Вы писали:

А>Офонареть. Silverlight не умеет DataTable.

А>И что прикажете подсовывать в качестве сорса DataGrid-у????


ObservableCollection<T>

Руководства читать не пробовал? На Channel 9 есть целый курс программирования на SL.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Аноним, Вы писали:

А>>Офонареть. Silverlight не умеет DataTable.

А>>И что прикажете подсовывать в качестве сорса DataGrid-у????


G>ObservableCollection<T>

А если у меня T нету, и набор колонок динамический, то какой подход посоветуете?

А>А если у меня T нету, и набор колонок динамический, то какой подход посоветуете?

Я в дотнете не силен, но какой-нибудь КастомТайпДескриптор не выручит?

Y>Я в дотнете не силен, но какой-нибудь КастомТайпДескриптор не выручит?
этого в Сильверлайте тоже нету.

А>А если у меня T нету, и набор колонок динамический, то какой подход посоветуете?
А что у вас есть? Т.е. надо в какой-нибудь класс завернуть аналог строки и положить в ObservableCollection. Все остальное хороший датагрид сам сделает. В общем случае, для T и Object сойдет. Собственно, вот в трех словах все основное:

To bind the DataGrid to data, set the ItemsSource property to an IEnumerable implementation. Each row in the data grid is bound to an object in the data source, and each column in the data grid is bound to a property of the data object. In order for the DataGrid user interface to update automatically when items are added to or removed from the source data, the DataGrid must be bound to a collection that implements INotifyCollectionChanged, such as an ObservableCollection<T>. In order to automatically reflect property changes, the objects in the source collection must implement the INotifyPropertyChanged interface.

Если совсем все динамическое, то можно тип в рантайме генерировать через Reflection.Emit.

Ну или что-нибудь коммерческое, вроде нашего C1.Silverlight.Data: www.componentone.com/SuperProducts/DataSilverlight/.
Может бесплатные аналоги есть, не искала.

Здравствуйте, Аноним, Вы писали:

А>Офонареть. Silverlight не умеет DataTable.

А>И что прикажете подсовывать в качестве сорса DataGrid-у????


Приходит в голову решение

class T
{
//стопицот однотипных мемберов
}

и задействовать столько мемберов в кач-ве колонок сколько надо.

Здравствуйте, notacat, Вы писали:

N>А что у вас есть? Т.е. надо в какой-нибудь класс завернуть аналог строки и положить в ObservableCollection. Все остальное хороший датагрид сам сделает. В общем случае, для T и Object сойдет. Собственно, вот в трех словах все основное:

Сорри, есичо, я поверхностно сужу — характер такой. Вобщем я боюсь что не понял что Вы написали.

У меня динамический SQL — возвращает столько колонок сколько хочет пользователь.

Здравствуйте, notacat, Вы писали:

N>Если совсем все динамическое, то можно тип в рантайме генерировать через Reflection.Emit.

Спс, я попробую Emit — это интересно. Там какие-нибудь грабли есть, например: безумно медленно или конфликт с настройками безопасности?

А>Спс, я попробую Emit — это интересно. Там какие-нибудь грабли есть, например: безумно медленно или конфликт с настройками безопасности?
c безопасностью должно быть все нормально, а в остальные грабли не вдавалась, только видела, что в рабочих проектах люди используют

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, Аноним, Вы писали:

А>>>Офонареть. Silverlight не умеет DataTable.

А>>>И что прикажете подсовывать в качестве сорса DataGrid-у????


G>>ObservableCollection<T>

А>А если у меня T нету, и набор колонок динамический, то какой подход посоветуете?

ObservableCollection<dynamic>, ObservableCollection<IDictionary<string, object>>

Здравствуйте, Аноним, Вы писали:

А>Приходит в голову решение

А>

А>class T
А>{
А>//стопицот однотипных мемберов
А>}
А>

А>и задействовать столько мемберов в кач-ве колонок сколько надо.

Это отличное решение в том случае, если мемберы изготовятся сами.

Здравствуйте, gandjustas, Вы писали:

G>ObservableCollection<dynamic>, ObservableCollection<IDictionary<string, object>>

Не могли бы Вы кодом или ссылками сопроводить? Не понимаю как сделать.

Здравствуйте, hardcase, Вы писали:

H>Здравствуйте, Аноним, Вы писали:

А>>Приходит в голову решение

А>>

А>>class T
А>>{
А>>//стопицот однотипных мемберов
А>>}
А>>

А>>и задействовать столько мемберов в кач-ве колонок сколько надо.

H>Это отличное решение в том случае, если мемберы изготовятся сами.

А чо усложнять — зажму Ctrl+C и готово. Не, правда, ребят, не такое уж и плохое решение.

а ваш динамический SQL в каком виде данные возвращает?

Здравствуйте, notacat, Вы писали:

N>а ваш динамический SQL в каком виде данные возвращает?

В DbDataReader:

DbCommand.ExecuteReader();

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, gandjustas, Вы писали:

G>>>Здравствуйте, Аноним, Вы писали:

А>>>>Офонареть. Silverlight не умеет DataTable.

А>>>>И что прикажете подсовывать в качестве сорса DataGrid-у????


G>>>ObservableCollection<T>

А>>А если у меня T нету, и набор колонок динамический, то какой подход посоветуете?

G>ObservableCollection<dynamic>, ObservableCollection<IDictionary<string, object>>

лучше все-таки ObservableCollection<IDictionary<string, object>> — позволяет использовать биндинги с индексаторами

Если выбирать между ObservableCollection<Dictionary<string,object>> и System.Reflection.Emit, то что выбрать?

В Emit-е в етот ихний «ассемблер» надо вникать, а зато O.C.<Dict<>> кмк кучу всего надо учесть, что, потенциально, таит тонны граблей.

Склоняюсь к emit-у, но До этого склонялся к DataTable и вона чо вышло. Кто знает оба подхода (ObCo и Emit) не могли б Вы сделать для меня обоснованный выбор?

Здравствуйте, Аноним, Вы писали:

А>Если выбирать между ObservableCollection<Dictionary<string,object>> и System.Reflection.Emit, то что выбрать?

А>В Emit-е в етот ихний «ассемблер» надо вникать, а зато O.C.<Dict<>> кмк кучу всего надо учесть, что, потенциально, таит тонны граблей.

А>Склоняюсь к emit-у, но До этого склонялся к DataTable и вона чо вышло. Кто знает оба подхода (ObCo и Emit) не могли б Вы сделать для меня обоснованный выбор?

ObservableCollection<IDictionary<string, object>> с собственной реализацией IDictionary. Тогда никаких граблей, определяете только то, что вам нужно.

Здравствуйте, bober_maniac, Вы писали:

_>Здравствуйте, Аноним, Вы писали:

А>>Если выбирать между ObservableCollection<Dictionary<string,object>> и System.Reflection.Emit, то что выбрать?

А>>В Emit-е в етот ихний «ассемблер» надо вникать, а зато O.C.<Dict<>> кмк кучу всего надо учесть, что, потенциально, таит тонны граблей.

А>>Склоняюсь к emit-у, но До этого склонялся к DataTable и вона чо вышло. Кто знает оба подхода (ObCo и Emit) не могли б Вы сделать для меня обоснованный выбор?

_>ObservableCollection<IDictionary<string, object>> с собственной реализацией IDictionary. Тогда никаких граблей, определяете только то, что вам нужно.

Грабли как раз в том что я не знаю заранее что «оно само сделаит» из того что мне нужно, а что определять надо. Т.е. я думаю что оно и так должно быть (само собой), а его вдруг не будет (потому что не определено).

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, bober_maniac, Вы писали:

_>>Здравствуйте, Аноним, Вы писали:

А>>>Если выбирать между ObservableCollection<Dictionary<string,object>> и System.Reflection.Emit, то что выбрать?

А>>>В Emit-е в етот ихний «ассемблер» надо вникать, а зато O.C.<Dict<>> кмк кучу всего надо учесть, что, потенциально, таит тонны граблей.

А>>>Склоняюсь к emit-у, но До этого склонялся к DataTable и вона чо вышло. Кто знает оба подхода (ObCo и Emit) не могли б Вы сделать для меня обоснованный выбор?

_>>ObservableCollection<IDictionary<string, object>> с собственной реализацией IDictionary. Тогда никаких граблей, определяете только то, что вам нужно.

А>Грабли как раз в том что я не знаю заранее что «оно само сделаит» из того что мне нужно, а что определять надо. Т.е. я думаю что оно и так должно быть (само собой), а его вдруг не будет (потому что не определено).

Именно поэтому IDictionary, а не Dictionary.

Здравствуйте, bober_maniac, Вы писали:

А>>Грабли как раз в том что я не знаю заранее что «оно само сделаит» из того что мне нужно, а что определять надо. Т.е. я думаю что оно и так должно быть (само собой), а его вдруг не будет (потому что не определено).

_>Именно поэтому IDictionary, а не Dictionary.

эээ.. Интеррресно интеррресно.. Т.е. реализую этот ифейс и всё — можно будет про эту деталь проекта забыть навсегда и пользоваться направо и налево ничего не правя в коде?
Мне надо чтоб работало и не парило моск, потому что задача у меня другая — ну там прорва бизнес-логики и всякие такие мелочи прорабатывать некогда.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, bober_maniac, Вы писали:

А>>>Грабли как раз в том что я не знаю заранее что «оно само сделаит» из того что мне нужно, а что определять надо. Т.е. я думаю что оно и так должно быть (само собой), а его вдруг не будет (потому что не определено).

_>>Именно поэтому IDictionary, а не Dictionary.

А>эээ.. Интеррресно интеррресно.. Т.е. реализую этот ифейс и всё — можно будет про эту деталь проекта забыть навсегда и пользоваться направо и налево ничего не правя в коде?
А>Мне надо чтоб работало и не парило моск, потому что задача у меня другая — ну там прорва бизнес-логики и всякие такие мелочи прорабатывать некогда.

Вы реализуете слой конверсии из ваших объектов с кучей полей в некий MyDictionary : IDictionary<string, object> и радуетесь жизни. Те методы IDictionary, которые вам не нужны, просто не реализуете.

А>В DbDataReader:

А>

А>DbCommand.ExecuteReader();
А>

Это со стороны сервера, а на клиент-то вы в каком виде собираетесь отдавать? Советую сначала об этом подумать, а потом уже про датагрид

Здравствуйте, bober_maniac, Вы писали:

_>Вы реализуете слой конверсии из ваших объектов с кучей полей в некий MyDictionary : IDictionary<string, object> и радуетесь жизни. Те методы IDictionary, которые вам не нужны, просто не реализуете.

Можно пример?

Исходные данные: Есть поток данных вида

{
1. Имя поля
2. Тип
3. Значение
} повторить 1 тире N раз

. Этот поток образует прямоугольную таблицу.

Здравствуйте, notacat, Вы писали:

А>>В DbDataReader:

А>>

А>>DbCommand.ExecuteReader();
А>>

N>Это со стороны сервера, а на клиент-то вы в каком виде собираетесь отдавать? Советую сначала об этом подумать, а потом уже про датагрид

В соседней ветке -- "DataTable vs Самопальный что-то там" -- это описано возможно более подробно.

Есть два рабочих проверенных варианта: 1. Передача DataSet/DataTable средствами WCF и 2. Преобразование DataTable/DataSet в свой тип-коллекцию и передача опять-таки средствами WCF (тут на самом деле я из DbDataReader читаю и строю этот тип-коллекцию минуя DataT/DataS)

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, bober_maniac, Вы писали:

_>>Вы реализуете слой конверсии из ваших объектов с кучей полей в некий MyDictionary : IDictionary<string, object> и радуетесь жизни. Те методы IDictionary, которые вам не нужны, просто не реализуете.

А>Можно пример?

А>Исходные данные: Есть поток данных вида

А>{
А>1. Имя поля
А>2. Тип
А>3. Значение
А>} повторить 1 тире N раз

А>. Этот поток образует прямоугольную таблицу.\

PS. я нарыл в инете пример, в каком-то блоге, копипаст, Рун. Открывается табличка с другим количеством колонок, без заголовков (или с заголовками которые в моем коде не упоминались), с пустыми ячейками. Вот.

А>Есть два рабочих проверенных варианта: 1. Передача DataSet/DataTable средствами WCF и 2. Преобразование DataTable/DataSet в свой тип-коллекцию и передача опять-таки средствами WCF (тут на самом деле я из DbDataReader читаю и строю этот тип-коллекцию минуя DataT/DataS)
Разбирать сериализованные DataSet/DataTable на клиенте — это для вас будут лишние сложности. Лучше уж тогда свои объекты и коллекции.

зыЖ это я говорю как человек, который этих устриц ел

Здравствуйте, notacat, Вы писали:

А>>Есть два рабочих проверенных варианта: 1. Передача DataSet/DataTable средствами WCF и 2. Преобразование DataTable/DataSet в свой тип-коллекцию и передача опять-таки средствами WCF (тут на самом деле я из DbDataReader читаю и строю этот тип-коллекцию минуя DataT/DataS)
N>Разбирать сериализованные DataSet/DataTable на клиенте — это для вас будут лишние сложности. Лучше уж тогда свои объекты и коллекции.

Это воще не проблема.. т.к. Silverlight (а мне надо прикрутить именно к нему) просто не умеет DataTable/DataSet ваобще

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, notacat, Вы писали:

N>>Если совсем все динамическое, то можно тип в рантайме генерировать через Reflection.Emit.

А>Спс, я попробую Emit — это интересно. Там какие-нибудь грабли есть, например: безумно медленно или конфликт с настройками безопасности?

Готово Копипастой с MSDN и нембольшим проектированием.

Такой вопрос: созданные таким образом типы как-нибудь удалять надо/можно? Или оне автоматически уходят в небытие (правда не пойму как думатель узнает что Тип пора кокнуть)?

А>Это воще не проблема.. т.к. Silverlight (а мне надо прикрутить именно к нему) просто не умеет DataTable/DataSet ваобще
У вас какая-то путаница. Сильверлайт же не умеет DataReader, но вы про него писали зачем-то. Вы уж определитесь, я же вас спросила как вы будете отдавать данные на клиент, и это вы опять про датасет написали. Перечитайте ветку повыше.
Сильверлайт умеет xml, и этого в принципе достаточно, чтобы на клиенте раскрутить даже датасет. Мы это у себя делаем.
Но если у вас нет готовой реализации для сильверлайта, то лучше про этот вариант не думать, а сразу заняться своими коллекциями.

Здравствуйте, notacat, Вы писали:

А>>Это воще не проблема.. т.к. Silverlight (а мне надо прикрутить именно к нему) просто не умеет DataTable/DataSet ваобще
N>У вас какая-то путаница. Сильверлайт же не умеет DataReader, но вы про него писали зачем-то. Вы уж определитесь, я же вас спросила как вы будете отдавать данные на клиент, и это вы опять про датасет написали. Перечитайте ветку повыше.
N>Сильверлайт умеет xml, и этого в принципе достаточно, чтобы на клиенте раскрутить даже датасет. Мы это у себя делаем.
N>Но если у вас нет готовой реализации для сильверлайта, то лучше про этот вариант не думать, а сразу заняться своими коллекциями.

Да, эт верно. (я допускаю что со стороны это выглядит Путаницей ещо той).

Просто тестил я поначалу в консоли на полном фреймворке, и у меня был выбор: DataTable vs Коллекции. С DataTable всё на порядок проще. Потом когда стал детализировать (тестировать на SL), то ГРРРРР узнал что с DataTable придётся завязать.

У меня трёхзвёнка. Среднее звено читает DbDataReader — раньше в DataTable, а теперь в коллекцию — которые отправляет клиенту WCF-ом.

Вот, щас клиент получает коллекции, дальше я создаю подходящий тип, по Вашей подсказке, и сую в DataGrid, который для моего типа сам столбцы — «гадский папа» — не строит. Ща биндинги изучаю штоб сказку сделать былью.