Есть проект WPF Core. На форме лежит DevExpress GridControl. Источник данных — ITable<MyDateMain> от linq2db. Некоторые колонки используют LookUpEdit для отображения подчиненных гридов. И вот тут начинаются сложности, потому что данные для подчиненных гридов должны запрашиваться в БД на основе нескольких полей из главенствующего грида.
Если бы в xaml можно было написать что-то вроде {Binding MyDateSub1(RowData.Row.Row)} это решило бы проблему, но, насколько я знаю — так сделать нельзя.
Можно попытаться наследоваться от MyDateMain внеся туда свойства вызывающие подчиненные данные. Но я не очень представляю как из ITable<MyDateMain> сделать ITable<MyDateMainChild>. Нет, можно, конечно что-то типа .select(d=>new MyDateMainChild(d)) , но строк в запросе довольно много и сколько будет время проводиться переработка — вопрос.
Здравствуйте, CyberRussia, Вы писали:
CR>Добрый день,
CR>Есть проект WPF Core. На форме лежит DevExpress GridControl. Источник данных — ITable<MyDateMain> от linq2db. Некоторые колонки используют LookUpEdit для отображения подчиненных гридов. И вот тут начинаются сложности, потому что данные для подчиненных гридов должны запрашиваться в БД на основе нескольких полей из главенствующего грида. CR>Если бы в xaml можно было написать что-то вроде {Binding MyDateSub1(RowData.Row.Row)} это решило бы проблему, но, насколько я знаю — так сделать нельзя. CR>Можно попытаться наследоваться от MyDateMain внеся туда свойства вызывающие подчиненные данные. Но я не очень представляю как из ITable<MyDateMain> сделать ITable<MyDateMainChild>. Нет, можно, конечно что-то типа .select(d=>new MyDateMainChild(d)) , но строк в запросе довольно много и сколько будет время проводиться переработка — вопрос.
CR>Как решить проблему?
Сумбурно как-то, зачем LookupEdit для отображения?
Я лет 10 не залазил в UI, и понять не могу чего вы добиваетесь.
Если что, меняйте DataSource для LookupEdit при изменении текущей строки.
Здравствуйте, Danchik, Вы писали: D>Сумбурно как-то, зачем LookupEdit для отображения?
Для создания подчиненных гридов из ячейки родительского. D>Я лет 10 не залазил в UI, и понять не могу чего вы добиваетесь.
А зачем тогда советуете? D>Если что, меняйте DataSource для LookupEdit при изменении текущей строки.
Как вы себе это представляете?
Здравствуйте, CyberRussia, Вы писали:
CR>Добрый день,
CR>Есть проект WPF Core. На форме лежит DevExpress GridControl. Источник данных — ITable<MyDateMain> от linq2db.
Юзать модель БД для модели Грида — плохая идея.
CR>Некоторые колонки используют LookUpEdit для отображения подчиненных гридов. И вот тут начинаются сложности, потому что данные для подчиненных гридов должны запрашиваться в БД на основе нескольких полей из главенствующего грида.
Или 1) в LookUpEdit.Value совать все необходимые поля строки. В этом случае будет один Editor-он каждую колонку грида.
Или 2) Генерировать для каждой ячейки свой едитор в момент Popup-а. Это геморно и тормозить может.
CR>Как решить проблему?
Для начала перестать юзать одну модель и для БД и для Грида
VC>Юзать модель БД для модели Грида — плохая идея.
Поясните.
VC>Или 1) в LookUpEdit.Value совать все необходимые поля строки. В этом случае будет один Editor-он каждую колонку грида.
Не понял, если честно.
VC>Или 2) Генерировать для каждой ячейки свой едитор в момент Popup-а. Это геморно и тормозить может.
Editor прописывается в xaml . Не вижу смысла его динамически генерировать.
VC>Для начала перестать юзать одну модель и для БД и для Грида
См.выше — поясните свою мысль.
Здравствуйте, CyberRussia, Вы писали:
CR>Здравствуйте, Danchik, Вы писали: D>>Сумбурно как-то, зачем LookupEdit для отображения? CR>Для создания подчиненных гридов из ячейки родительского. D>>Я лет 10 не залазил в UI, и понять не могу чего вы добиваетесь. CR>А зачем тогда советуете?
Ничерта я не советую, потому что вопрос непонятен. Хоть картинку бы запостил.
А советую потому что собаку на этом скушал и в принципе понимаю как грид работает.
D>>Если что, меняйте DataSource для LookupEdit при изменении текущей строки. CR>Как вы себе это представляете?
На скриншоте не видно шаблона подчиненного грида, но LookUpEditSettings ссылается на него.
Но вопрос в подключении данных, то ли создавать единый класс содержаний в себя все данные по строке, включая подчененные гриды. То ли как-то по другому работать с Binding а не RowData.Row.DataGridSub1
Здравствуйте, CyberRussia, Вы писали:
D>>Какой-то приватный линк, скриншот что-ли сделайте D>>В ячейку вывести имя, а не ID? У меня такое чувство что мы в терминах путаемся.
CR>Два скриншота из Demo Center от DevExpress — Multi-Column Lookup Cell Editor CR>http://files.rsdn.org/57699/code.png — UI CR>http://files.rsdn.org/57699/code.png — Code (фрагмент)
CR>На скриншоте не видно шаблона подчиненного грида, но LookUpEditSettings ссылается на него.
CR>Но вопрос в подключении данных, то ли создавать единый класс содержаний в себя все данные по строке, включая подчененные гриды. То ли как-то по другому работать с Binding а не RowData.Row.DataGridSub1
Если только для отображения — однозначно прокидывать все колонки в запрос. Иначе будут невиданные тормоза. Для IQueryable это не проблема если грид потом сам делает проекцию.
Но есть и другой вариант:
Если T4 шаблон смог подхватить ваши FK, то у вашей модели есть ассоциации, а ассоциации должны легко байндится в таком виде
D>Если только для отображения — однозначно прокидывать все колонки в запрос. Иначе будут невиданные тормоза. Для IQueryable это не проблема если грид потом сам делает проекцию.
Запрос на основе которого строится основной грид сейчас выдает примерно 400 000 записей. В трех подчиненных гридах примерно по 100, и в двух по 10 на каждую строку родительского. Я боюсь, что если это все в один запрос свести, то пользователь просто не дождется результата.
D>Но есть и другой вариант: D>Если T4 шаблон смог подхватить ваши FK, то у вашей модели есть ассоциации, а ассоциации должны легко байндится в таком виде
Не подумал о таком. Посмотрю, когда доберусь до рабочего компа, но есть сомнения. Запросы строились на основе View БД, так что ассоциации в linq2db могли и не появиться.
Здравствуйте, CyberRussia, Вы писали:
D>>Если только для отображения — однозначно прокидывать все колонки в запрос. Иначе будут невиданные тормоза. Для IQueryable это не проблема если грид потом сам делает проекцию. CR>Запрос на основе которого строится основной грид сейчас выдает примерно 400 000 записей. В трех подчиненных гридах примерно по 100, и в двух по 10 на каждую строку родительского. Я боюсь, что если это все в один запрос свести, то пользователь просто не дождется результата.
Я что-то путаюсь. При чему тут подчиненный грид? Выдаете данные в одну строку?
Или у вас рядом лежит еще парочка гридов (уже телепатия какая-то)
D>>Но есть и другой вариант: D>>Если T4 шаблон смог подхватить ваши FK, то у вашей модели есть ассоциации, а ассоциации должны легко байндится в таком виде CR>Не подумал о таком. Посмотрю, когда доберусь до рабочего компа, но есть сомнения. Запросы строились на основе View БД, так что ассоциации в linq2db могли и не появиться.
D>Я что-то путаюсь. При чему тут подчиненный грид? Выдаете данные в одну строку? D>Или у вас рядом лежит еще парочка гридов (уже телепатия какая-то)
Есть грид. Основной. Он же родительский. Основа — примерно 400 000 записей в БД.
Клик на ячейку — открывается новый грид (подчиненный), новый запрос в БД с параметрами из строки родительского грида. Разные столбцы — разные структуры подчиненных гридов, разные (в разные view) запросы к БД. Разные строки — разные параметры для запроса. Примерно на каждый такой грид — 100 записей из БД.
Здравствуйте, CyberRussia, Вы писали:
D>>Я что-то путаюсь. При чему тут подчиненный грид? Выдаете данные в одну строку? D>>Или у вас рядом лежит еще парочка гридов (уже телепатия какая-то)
CR>Есть грид. Основной. Он же родительский. Основа — примерно 400 000 записей в БД. CR>Клик на ячейку — открывается новый грид (подчиненный), новый запрос в БД с параметрами из строки родительского грида. Разные столбцы — разные структуры подчиненных гридов, разные (в разные view) запросы к БД. Разные строки — разные параметры для запроса. Примерно на каждый такой грид — 100 записей из БД.
Тогда тому подчиненному гриду надо менять DataSource на клик или на смену строки — тут фильтруете уже по значениям с мастер грида, фактически новый IQueryable. Как бы логично.
Сомневаюсь что LookupEdit делает это автоматом
Ага. Я так для WinForms и ASP.NET писал. А вот в WPN с его XAML было желание обойтись именно XAML с Binding и соответствующей моделью.
В текущей реализации создал класс наследник от MyDateMain
public class MyDateMainEx : MyDateMain, IDisposable
{
public Data { get; set; }
public MyDateMainEx(MyDateMain DataParent): base()
{
Data = DataParent;
}
...
В который под видом публичных свойств прописал методы вызовы IQuarberly для подчиненных гридов, типа
