Имеем




CommonVM - обобщённый (generic) тип. Выдаётся ошибка, что-то типа "замл не может найти тип CommonVM". Встречал подобные жалобы в 2008 году. Летом 2011 тоже встречал. Использую 4 версию фреймворка. Неужели до сих пор замл из коробки не поддерживает шаблоны данных для обобщённых типов?

Как обойти эту ошибку, чтобы шаблон стал поддерживать? Хочу привязаться (binding) к экземпляру обобщённого типа.

МСУuser7320Как обойти эту ошибку, чтобы шаблон стал поддерживать? Хочу привязаться (binding) к экземпляру обобщённого типа.



Я генерик специально завёл, чтобы оборачивать типы типа таких:




где Т - всякие типы значений должны быть (я потом добавлю ограничение where - щас для примера сказал). А теперь что будет с Т Value, если я унаследую конкретный тип от обобщённого? Какой тип пример Т?

Или это просто уловка такая, костыль для замла, и не несёт никакого добавочного смысла? И Т можно задать, вызвав базовый конструктор (т. е. конструктор обобщённого типа) в конструкторе конкретного типа?

Вы мне скажите, в свете этого

авторЯ генерик специально завёл, чтобы оборачивать типы типа таких:

мне придётся создавать столько конкретных типов, сколько я хочу типов передать в Т, или как? Тогда теряется смысл в обёртке и обобщённом типе как таково - я его использовал специально, чтобы обёртка была одна на все типы.

SeVauser7320Вы мне скажите, в свете этого

пропущено...


мне придётся создавать столько конкретных типов, сколько я хочу типов передать в Т, или как? Тогда теряется смысл в обёртке и обобщённом типе как таково - я его использовал специально, чтобы обёртка была одна на все типы.

Встань на место xaml и попробуй придумать, как ты будешь в одно темплейте обрабатывать любые данные.
Тогда уже требуй, чтобы в C# был только один тип данных на все случаи жизни - сделайте мне красиво и точка.
Ну замл же может распаковывать все обджекты в числовые данные (или не может?) - почему, если я не ограничу обобщённый тип тоже числовыми данными в параметре типа, он не может также делать?

И это, а если мне надо все данные представлять строками - ТуСтринг() есть для всех типов - то почему я и в этом случае должен для всех типов писать одинаковый шаблон данных, который будет только названием отличаться и тем, что забайндин к конкретному типу? Ещё раз: можно же сделать разумное послабление - разрешить для числовых типов, а также для строк обобщённые шаблоны данных в представлениях.

Понимаете, у меня такая штука. У меня в модели представления есть группы данных. Каждая группа - один неконкретный тип (инт, дабл, бул и прочие) и пара строковых. Я хочу представить эти группы в представлении обобщённо - одним шаблоном. Но раз нельзя сделать обобщённый шаблон, то, по-вашему, надо делать по шаблону на каждый неизвестный тип в группе. Так?

Т. е. если существуют кортежи данных, в которых хотя бы одно данное имеет неконкретный тип, то представить такой кортеж одним шаблоном в замле на текущий момент нельзя? Т. е. нет в замле обобщённых шаблонов данных, так? Т. е. единственный выход для минимизации разводимых типов и шаблонов - выделить из таких кортежей общую часть и представлять её отдельно в виде одного шаблона, а изменяющуюся (от одного кортежа к другому) часть неконкретного типа представлять каждый раз разным (подходящим) контролом или шаблоном. Т. е. тут уж никуда не десться - ограничение инструментария. Я правильно рассуждаю?

У меня, собственно, на данный момент пока именно такая реализация - выделение из каждого кортежа совпадающих по типу частей и неконкретных по типу частей и представление совпадающих одним шаблоном данных (для которого в модели представления заведён специальный тип), а несовпадающих - каждый раз своим контролом.

Но недостаток такого метода я вижу такой - приходится на каждое свойство неконкретного типа заводить по одному свойству типа, объединяющего общие по типам данные кортежей. Т. е. сколько я таких объединений по типам данных делаю, во столько РАЗ количество свойств увеличивается.

И я всё же не понимаю этой недоработки. Почему в модели, на языке C# можно представлять обобщённые сущности, а в представлении в замле - нельзя? Почему в замле надо разделять ЕДИНУЮ И НЕДЕЛИМУЮ ПО СМЫСЛУ сущность на куски и представлять отдельно обобщённую и отдельно неконкретную части? Недоработка-с...

SeVauser7320У меня, собственно, на данный момент пока именно такая реализация - выделение из каждого кортежа совпадающих по типу частей и неконкретных по типу частей и представление совпадающих одним шаблоном данных (для которого в модели представления заведён специальный тип), а несовпадающих - каждый раз своим контролом.

Но недостаток такого метода я вижу такой - приходится на каждое свойство неконкретного типа заводить по одному свойству типа, объединяющего общие по типам данные кортежей. Т. е. сколько я таких объединений по типам данных делаю, во столько РАЗ количество свойств увеличивается.

И я всё же не понимаю этой недоработки. Почему в модели, на языке C# можно представлять обобщённые сущности, а в представлении в замле - нельзя? Почему в замле надо разделять ЕДИНУЮ И НЕДЕЛИМУЮ ПО СМЫСЛУ сущность на куски и представлять отдельно обобщённую и отдельно неконкретную части? Недоработка-с...

Это не доработки, а кривые подходы. Обобщенным должен быть только viewmodel, обобщенные типы данных - маразм, а в xaml должна быть только композиция, которая делается в несколько строк.
Ну вот как бы вы сделали, будь у вас разнотипные данные, а к ним однотипные данные, и вам бы надо было каждое разнотипное данное сгруппировать с однотипным? Например, кучка разнотипных настроек и однотипных (в смысле, что типа стринг, а не в смысле, что одно и то же содержание) описаний к ним - надо к каждой настройке описание приделать.

Почему желательно сделать это шаблонным подходом? Да потому что представление сложное - с анимациями, стилями и прочим. Если для каждой такой группы описание-настройка делать свой шаблон - шаблонов не напасёшься. Если без шаблонов, а всё писать в одном документе замл, то документ на десять экранов будет. Анимация просто так не подключается - из-за особенностей реализации анимаций в замл. Так вот, анимируются контролы, относящиеся к однотипным данные - строковым. Значит, их можно вынести в один шаблон данным, к которому привязывать эти строки. Это нормально. Но тогда сгруппировать с разнотипными данными (как и было поставлено в задаче) не получится - замл не воспринимает обобщённых шаблонов данных (я даже согласен, что логика в этом есть). Тогда остаётся одно - не группировать разнотипные данные с однотипными - т. е. настройки с их описаниями. Это нарушает логику интерфейса и вообще логику - настройки и их описания должны быть вместе.

Поясню на картинке.

У меня есть настройки, представляющие из себя кортежи (значение - неконкретный тип, название - строка, описание - строка). Хочу сделать так, как на верхней половине картинки. Соответственно, для шаблона я завёл отдельный тип данных (в модели представления), содержащий один параметр типа - т. е. обобщённый тип данных. Кроме того, условие - при наведении на панель или любой из её потомков по визуальному дереву, должна анимацией показываться кнопка (прозрачность со 100% до 0) и наоборот. Поначалу кнопка невидна (прозрачность 100%).

А из-за отсутствия подобного обобщённого шаблона данных в замле, пришлось сделать так, как показано на нижней половине рисунка. Соответственно, создан тип для кортежа (название, описание), но уже не обобщённый, а само значение байндится сразу к контролу, без всяких шаблонов. Соответственно, когда наводишь на контрол, представляющий значение, кнопка не анимируется. В результате, хотя визуально и кажется, будто весь кортеж представляет собой единое целое, что и нужно ПО СМЫСЛУ, в визуальном дереве значение и его описание с названием разделены.

Вы считаете, это нормально? Ведь есть контролы, которые могут принимать любое числовое значение, а есть вообще просто текстбоксы, которые могут и числа принимать, а потом просто парсят их в нужный тип. Почему это обойдено создателями замла и сделано всё очень неудобно для ситуаций, подобных описанной мной?

МСУuser7320, на пустом месте без видимых на то обстоятельств ты генерируешь слишком много текста. Лениво читать...
Да вы хотя бы последний мой пост с картинкой почитайте. Мы на самом деле уже не отвечаем на первый вопрос, а продолжаем разговор дальше. Ну, не начинать же новую тему. Вот я привёл пример моего задания и желаю узнать, как бы его решили вы и что вы скажете о моём решении.

МСУuser7320Как обойти эту ошибку, чтобы шаблон стал поддерживать? Хочу привязаться (binding) к экземпляру обобщённого типа.


Как жить в этом мире, если одни пишет одно, а другой - другое ?

Там на ответ (зелёной галочкой обозначен) гляньте.

SeVaGluck_13user7320,

Вкратце, можно так:
1. Выделить базовый (не-generic) класс вьюмодели.
2. Сделать для него DataTemplate - панель с названием, кнопкой и ContentControl-ом для Value с ContentTemplateSelector, возвращающим нужный DataTemplate в зависимости от типа Value.

ContentTemplateSelector не нужен. В пятом sl есть implicit datatemplate
У меня WPF.

Gluck_13user7320,

Вкратце, можно так:
1. Выделить базовый (не-generic) класс вьюмодели.
2. Сделать для него DataTemplate - панель с названием, кнопкой и ContentControl-ом для Value с ContentTemplateSelector, возвращающим нужный DataTemplate в зависимости от типа Value.
Я тут всё равно не понял, как это сократит сущности в модели представления. В представлении, как видно из вашего описания, ничего уже не сократится - всё равно по шаблону данных на тип данных Value. В модели представления базовый тип - он должне содеражать поле для Value или нет? Если да, то это поле будет object? - Тогда сложности с его обработкой - к какому типу приводить (я использую всякие TryParse() для конкретных числовых типов - т. е. методы, зависимые от типа). Если нет, то распознает ли привязка к базовому типу отсутствующее в этом базовом типе поле?

Вобщем, я прикинул, возни и так, и так много, и сущностей толком не убавляется при любом раскладе. Тогда оставил просто тот вариант, что у меня раньше был (на второй половине картинки) - с дополнительным полем для каждого Value, обозначающем тип с названием и описанием этого Value.

SeVaДелается обобщенный viewmodel

public class viewmodel<T>
{
public T Model { get; set; }
}

Если нужен заголовок, то он может быть отдельным свойством Title в Model или переопределить для него ToString(), или в viewmodel

a'la

public T Model { set { UpdateModelTitle(value); _modelTitle = value; }}

Но проще всего не усложнять все на ровном месте из одной строчки
Так я же говорю, обобщённый тип не привязывается в замле - там в шаблоне данных в его свойстве DataType нельзя указать обобщённый тип. Т. е. контролы, могущие принимать разные типы для одного и того же своего свойства, есть, а шаблон данных, который бы принимал обобщённый тип для этих контролов, сделать нельзя.