Почему нету статической проверки биндингов в Xaml? Я из-за этого приложение не рабочее опубликовал — кто же знал, что к перенесенному мной в другой класс свойству где-то биндинги есть?
И зачем там вообще динамика нужна? Почему, например Template Parts находятся динамически по именам?
Может какая сторонняя тулза умеет такие ошибки находить?
14.08.11 17:41: Перенесено модератором из '.NET' — VladD2
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>Почему нету статической проверки биндингов в Xaml? Я из-за этого приложение не рабочее опубликовал — кто же знал, что к перенесенному мной в другой класс свойству где-то биндинги есть?
By design. Source может прийти из любого источника выше по дереву, и, более того, может быть заменён в любой момент. Если не нравится — добавляйте свои листенеры к PresentationTraceSources и дёргайте из них Debugger.Break() (ну, или просто кидайте исключения).
ЕА>Может какая сторонняя тулза умеет такие ошибки находить? http://karlshifflett.wordpress.com/2009/06/08/glimpse-for-silverlight-viewing-exceptions-and-binding-errors/
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>Может какая сторонняя тулза умеет такие ошибки находить?
ReSharper умеет делать комплишн к биндингам если знает тип Source (ему можно подсказать этот тип design-level атрибутом), соответственно после этого Path биндинга будет участвовать во всех рефакторингах и прочем.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>>Почему нету статической проверки биндингов в Xaml? Я из-за этого приложение не рабочее опубликовал — кто же знал, что к перенесенному мной в другой класс свойству где-то биндинги есть? S>By design. Source может прийти из любого источника выше по дереву, и, более того, может быть заменён в любой момент. Если не нравится — добавляйте свои листенеры к PresentationTraceSources и дёргайте из них Debugger.Break() (ну, или просто кидайте исключения).
Вот почему такой By Design мне и не понятно, в смысле понятно, что иногда это необходимо, но почему было типизированный вариант не предусмотреть?
Исключение там кидалось — прикол в том, что никто эту форму при тестировании повторно не открыл, а покрывать Unit тестами формочки, где нет вообще не одной строчки кода, как-то глупо.
Здравствуйте, Пельмешко, Вы писали:
П>Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>>Может какая сторонняя тулза умеет такие ошибки находить?
П>ReSharper умеет делать комплишн к биндингам если знает тип Source (ему можно подсказать этот тип design-level атрибутом), соответственно после этого Path биндинга будет участвовать во всех рефакторингах и прочем.
Не, я хочу именно статическую проверку — а то изменения вносятся разными людьми, одновременно и не всегда с помощью рефакторинга
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>Вот почему такой By Design мне и не понятно, в смысле понятно, что иногда это необходимо, но почему было типизированный вариант не предусмотреть?
Ок, как он должен выглядеть?
Для простых DataTemplate всё элементарно, как быть со сложными случаями — кастомные property descriptor-ы (например, датасеты), биндинг ч/з RelativeSource, конвертеры, биндинг к контексту?
Я не спорю, что отлаживать такие случаи — сплошной гемморой, просто решения универсального не проглядывается. Или урезать биндинг до состояния "не нравится — пиши сам", или мириться с динамикой, иначе никак.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>>Вот почему такой By Design мне и не понятно, в смысле понятно, что иногда это необходимо, но почему было типизированный вариант не предусмотреть? S>Ок, как он должен выглядеть?
S>Для простых DataTemplate всё элементарно, как быть со сложными случаями — кастомные property descriptor-ы (например, датасеты), биндинг ч/з RelativeSource, конвертеры, биндинг к контексту?
я бы предпочел как в Си-шарп — нужна позарез динамика — пиши dynamic и вперед, не нужна динамика — все типизированно
про проперти descriptor-ы соглашусь, конверторы можно было сделать типизированными, RelativeSource — тоже в большинстве случаев тип известен, для контеста я бы обязал либо указывать тип где-то выше по иерархии, либо опять же эксплицитно указывать dynamic
а вообще идеально было бы использовать linq-е Expressions в биндинге — была бы и типизация, и возможность делать вычисления (а то задолбало уже конверторы писать)
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>я бы предпочел как в Си-шарп — нужна позарез динамика — пиши dynamic и вперед, не нужна динамика — все типизированно.
Вариант, тем более что в XAML-е уже используется подобный подход со статическими/динамическими ресурсами
Одно но — я по-прежнему не уверен, что большую часть биндингов удастся типизировать без сильного усложнения API. Чую, но обосновать не могу
ЕА>Исключение там кидалось — прикол в том, что никто эту форму при тестировании повторно не открыл, а покрывать Unit тестами формочки, где нет вообще не одной строчки кода, как-то глупо.
Почему глупо? Тогда уж ее и делать глупо было. Можно вот этим пользоваться: http://msdn.microsoft.com/en-us/library/dd286681.aspx, особенно если много народу код правит.
ЕА>Почему нету статической проверки биндингов в Xaml? Я из-за этого приложение не рабочее опубликовал — кто же знал, что к перенесенному мной в другой класс свойству где-то биндинги есть?
как вы себе это представляете? В том и смысл байндинга, что он динамический. В половине случаев ни в дизайн-тайме, ни тем более при компиляции в Source байндинга просто ничего нет, что проверять? Если динамика не нужна — не используйте байндинг
Здравствуйте, notacat, Вы писали:
ЕА>>Исключение там кидалось — прикол в том, что никто эту форму при тестировании повторно не открыл, а покрывать Unit тестами формочки, где нет вообще не одной строчки кода, как-то глупо. N>Почему глупо? Тогда уж ее и делать глупо было. Можно вот этим пользоваться: http://msdn.microsoft.com/en-us/library/dd286681.aspx, особенно если много народу код правит.
Не хочу, у меня есть оттестированные ViewModel, а весь UI чисто декларативный, рисуется в Бленде дизайнерами
Здравствуйте, notacat, Вы писали:
ЕА>>Почему нету статической проверки биндингов в Xaml? Я из-за этого приложение не рабочее опубликовал — кто же знал, что к перенесенному мной в другой класс свойству где-то биндинги есть? N>как вы себе это представляете? В том и смысл байндинга, что он динамический. В половине случаев ни в дизайн-тайме, ни тем более при компиляции в Source байндинга просто ничего нет, что проверять?
Я себе как раз динамический плохо представляю — к чему биндиться-то? То если источник не известен, то откуда узнать что в path писать, какие конвертеры использовать итд?
N>Если динамика не нужна — не используйте байндинг
Ну вот сейчас у меня программист делает ViewModel и пишет на нее тесты, а дизайнер в Expression Blend рисует как это выглядит, и делает байндинги к ViewModel. Ссылка на ViewModel есть в ресурсах, все типизированно, все типы Blend разбирает и позволяет все что надо подставлять визуально.
ЕА>Не хочу, у меня есть оттестированные ViewModel, а весь UI чисто декларативный, рисуется в Бленде дизайнерами
вы делаете ViewModel, дизайнеры что-то рисуют в Бленде, потом вы меняете ViewModel (вы писали, что перенесли свойства из одного класса в другой), а потом вы не хотите тестировать, что в итоге получилось. Если я это все верно отследила, то у вас тут явно чего-то не хватает. Неужели вы никогда не сталкивались с тем, что простой c# код строится нормально, а при этом не работает? Ну даже если кто-нибудь ваши байндинги будет проверять — все равно я бы ни за что это в production не выпустила.
ЕА>Я себе как раз динамический плохо представляю — к чему биндиться-то? То если источник не известен, то откуда узнать что в path писать, какие конвертеры использовать итд?
у вас что, статическое приложение, которое ниоткуда никаких данных не берет и ничего с ними не делает? Ну да, вы как разработчик можете знать, какой тип в этом байндинге в конечном счете должен появиться, но xaml loader'у об этом может быть неизвестно. И вообще есть куча вариантов, когда даже Бленд не может ничего разобрать, а в рантайме оно тем не менее будет работать. И наоборот.
N>>Если динамика не нужна — не используйте байндинг
ЕА>Ну вот сейчас у меня программист делает ViewModel и пишет на нее тесты, а дизайнер в Expression Blend рисует как это выглядит, и делает байндинги к ViewModel. Ссылка на ViewModel есть в ресурсах, все типизированно, все типы Blend разбирает и позволяет все что надо подставлять визуально.
ЕА>Что посоветуете вместо байндинга?
Чтобы при этом все остальное осталось на месте? Вряд ли посоветую.
Т.е., можно было бы извратиться и встроить проверку ошибок, но скорей всего из этого получится только длинное упражнение, в ходе которого вы поймете, почему байндинг динамический.
Сделайте лучше не Unit тест, который будет запускать ваше приложение и открывать все формочки по-очереди. Это должно быть более-менее элементарно.
Здравствуйте, notacat, Вы писали:
ЕА>>Не хочу, у меня есть оттестированные ViewModel, а весь UI чисто декларативный, рисуется в Бленде дизайнерами N>вы делаете ViewModel, дизайнеры что-то рисуют в Бленде, потом вы меняете ViewModel (вы писали, что перенесли свойства из одного класса в другой), а потом вы не хотите тестировать, что в итоге получилось. Если я это все верно отследила, то у вас тут явно чего-то не хватает. Неужели вы никогда не сталкивались с тем, что простой c# код строится нормально, а при этом не работает? Ну даже если кто-нибудь ваши байндинги будет проверять — все равно я бы ни за что это в production не выпустила.
Да я бы таких как я вообще к компьютеру не подпускал ... на милю ... под угрозой растрела
но все равно непонятно зачем в биндингах неотключаемая динамика — это старый аргумент всех любителей динамики, типа вы все равно других ошибок наделаете — так какая вам разница, на си-шарпе то код не скомпилируется, если будет обращаться к несуществующим сущностям, одним уровнем тестов меньше
Здравствуйте, notacat, Вы писали:
ЕА>>Я себе как раз динамический плохо представляю — к чему биндиться-то? То если источник не известен, то откуда узнать что в path писать, какие конвертеры использовать итд? N>у вас что, статическое приложение, которое ниоткуда никаких данных не берет и ничего с ними не делает?
Берет и даже что-то с ними делает, причем на типизированном языке. Интерестно, как это удается писать на си-шарпе работу с данными?
N>Ну да, вы как разработчик можете знать, какой тип в этом байндинге в конечном счете должен появиться, но xaml loader'у об этом может быть
неизвестно.
Т.е. разработчику тип известен, языку на котором написана обработка тип известен, а включить эту информацию в Xaml принципиально невозможно.
N> И вообще есть куча вариантов, когда даже Бленд не может ничего разобрать, а в рантайме оно тем не менее будет работать. И наоборот.
В сильверлайте на сегодняшний день я знаю одну ситуацию, когда тип задать не удастся — это невозможность задать тип в DataTemplate,(впрочем, в 5-м сильверлайте поправят). Зачем в других случаях мучить людей, я не знаю.
Сможете пример привести?
N>>>Если динамика не нужна — не используйте байндинг
ЕА>>Ну вот сейчас у меня программист делает ViewModel и пишет на нее тесты, а дизайнер в Expression Blend рисует как это выглядит, и делает байндинги к ViewModel. Ссылка на ViewModel есть в ресурсах, все типизированно, все типы Blend разбирает и позволяет все что надо подставлять визуально.
ЕА>>Что посоветуете вместо байндинга? N>Чтобы при этом все остальное осталось на месте? Вряд ли посоветую. N>Т.е., можно было бы извратиться и встроить проверку ошибок, но скорей всего из этого получится только длинное упражнение, в ходе которого вы поймете, почему байндинг динамический. N>Сделайте лучше не Unit тест, который будет запускать ваше приложение и открывать все формочки по-очереди. Это должно быть более-менее элементарно.
Можно конечно. Можно вообще весь код переписать на динамическом языке и все проблемы с типизациями решать тестами, только зачем?
ЕА>Берет и даже что-то с ними делает, причем на типизированном языке. Интерестно, как это удается писать на си-шарпе работу с данными?
Попробуйте написать то, что у вас есть в xaml'е на чистом шарпе. Как минимум вы будете делать проверки на null и как-то обрабатывать случаи, когда данных еще нет. Вы хотите, чтобы все эти ошибки в случае xaml'а просто не давали построить приложение? Или у вас есть какие-то другие варианты?
N>>Ну да, вы как разработчик можете знать, какой тип в этом байндинге в конечном счете должен появиться, но xaml loader'у об этом может быть ЕА>неизвестно.
ЕА>Т.е. разработчику тип известен, языку на котором написана обработка тип известен, а включить эту информацию в Xaml принципиально невозможно.
попробуйте сделать custom markup extension или свой класс байндинга написать, включите информацию о типе, кто вам мешает? Или хотя бы конвертер с параметром для этой цели используйте. Принципиально можно добавить иформацию в xaml, вопрос в том, гарантирует ли это вас от ошибок.
N>> И вообще есть куча вариантов, когда даже Бленд не может ничего разобрать, а в рантайме оно тем не менее будет работать. И наоборот. ЕА>В сильверлайте на сегодняшний день я знаю одну ситуацию, когда тип задать не удастся — это невозможность задать тип в DataTemplate,(впрочем, в 5-м сильверлайте поправят). Зачем в других случаях мучить людей, я не знаю.
Ну допустим. Но задать-то вы его зададите, а вот некоторые ошибки все равно только в рантайме получите. Когда попытаетесь этот темплейт не к тому типу применить. Начиная от того, что просто ошибетесь в неочевидном месте, и заканчивая тем, что снова поменяете ViewVodel и "кто же знал, что кто-то это уже использует"
N>>Сделайте лучше не Unit тест, который будет запускать ваше приложение и открывать все формочки по-очереди. Это должно быть более-менее элементарно. ЕА>Можно конечно. Можно вообще весь код переписать на динамическом языке и все проблемы с типизациями решать тестами, только зачем?
если незачем, то пожалуйста, публикуйте что попало, юзеры вам об ошибках сообщат, если захотят.
ЕА>но все равно непонятно зачем в биндингах неотключаемая динамика — это старый аргумент всех любителей динамики, типа вы все равно других ошибок наделаете — так какая вам разница, на си-шарпе то код не скомпилируется, если будет обращаться к несуществующим сущностям, одним уровнем тестов меньше
Я думаю, что большинство считает это фичей и с удовольствием пользуется.
Возьмите в руки рефлектор и предложите свой вариант отключения динамики. Потом посмотрим, будут ли от этого какие-то накладные расходы и в каком месте. Если покажется, что вариант хороший — напишите свое предложение в MS — они регулярно собирают предложения, голосования проводят, что важней и т.д. и т.п.
Здравствуйте, notacat, Вы писали:
ЕА>>Берет и даже что-то с ними делает, причем на типизированном языке. Интерестно, как это удается писать на си-шарпе работу с данными? N>Попробуйте написать то, что у вас есть в xaml'е на чистом шарпе. Как минимум вы будете делать проверки на null и как-то обрабатывать случаи, когда данных еще нет.
Вы хотите, чтобы все эти ошибки в случае xaml'а просто не давали построить приложение? Или у вас есть какие-то другие варианты?
Хочу, по крайней мере в большинстве случаев, а когда нужна динамика, пусть это указывается эксплицитно
N>>>Ну да, вы как разработчик можете знать, какой тип в этом байндинге в конечном счете должен появиться, но xaml loader'у об этом может быть ЕА>>неизвестно.
ЕА>>Т.е. разработчику тип известен, языку на котором написана обработка тип известен, а включить эту информацию в Xaml принципиально невозможно. N>попробуйте сделать custom markup extension или свой класс байндинга написать, включите информацию о типе, кто вам мешает? Или хотя бы конвертер с параметром для этой цели используйте. Принципиально можно добавить иформацию в xaml, вопрос в том, гарантирует ли это вас от ошибок.
N>>> И вообще есть куча вариантов, когда даже Бленд не может ничего разобрать, а в рантайме оно тем не менее будет работать. И наоборот. ЕА>>В сильверлайте на сегодняшний день я знаю одну ситуацию, когда тип задать не удастся — это невозможность задать тип в DataTemplate,(впрочем, в 5-м сильверлайте поправят). Зачем в других случаях мучить людей, я не знаю. N>Ну допустим. Но задать-то вы его зададите, а вот некоторые ошибки все равно только в рантайме получите. Когда попытаетесь этот темплейт не к тому типу применить. Начиная от того, что просто ошибетесь в неочевидном месте, и заканчивая тем, что снова поменяете ViewVodel и "кто же знал, что кто-то это уже использует"
Если написать статический анализатор, то да, это гарантированно исключит целый класс ошибок. Конечно, это не мешает делать другие ошибки, но уже меньше мест, где разложены грабли. Если бы это было не так, никто бы со статикой вообще не заморачивался. Предложенные вами варианты действительно никаких гарантий не дают и никаких проверок в компайл-тайме выполнять не будут.
N>>>Сделайте лучше не Unit тест, который будет запускать ваше приложение и открывать все формочки по-очереди. Это должно быть более-менее элементарно. ЕА>>Можно конечно. Можно вообще весь код переписать на динамическом языке и все проблемы с типизациями решать тестами, только зачем? N>если незачем, то пожалуйста, публикуйте что попало, юзеры вам об ошибках сообщат, если захотят.
т.е. вы совсем никогда-никогда никаких ошибок не делаете? и отдел тестирования никогда-никогда ничего не пропускает? и ваши партнеры, которые на базе вашего АПИ что-то делают тоже никогда-никогда не ошибаются? и небольших проектиков (ну типа вот демка для конкретного заказчика) для которых полноценное тестирование проводить нерентабельно, тоже не бывает? везет же людям
ЕА>Если написать статический анализатор, то да, это гарантированно исключит целый класс ошибок. Конечно, это не мешает делать другие ошибки, но уже меньше мест, где разложены грабли. Если бы это было не так, никто бы со статикой вообще не заморачивался. Предложенные вами варианты действительно никаких гарантий не дают и никаких проверок в компайл-тайме выполнять не будут.
ну если еще билд допилить, то можно добиться определенных гарантий. Только смысл у этого будет тот же самый, что сделать простой тест открывающий формочки, а вы этого не хотите.
ЕА>т.е. вы совсем никогда-никогда никаких ошибок не делаете? и отдел тестирования никогда-никогда ничего не пропускает? и ваши партнеры, которые на базе вашего АПИ что-то делают тоже никогда-никогда не ошибаются? и небольших проектиков (ну типа вот демка для конкретного заказчика) для которых полноценное тестирование проводить нерентабельно, тоже не бывает? везет же людям
ха-ха, надо тоже про руботу в профиле написать
