WPF databinding

6yrop

а что, действительно, в WPF, чтобы вывести имя большими буквами, столько кода надо написсать?
 


<Application.Resources> 

    <local:StringToUpperCaseConverter x:Key=”stringConverter”/> 

</Application.Resources> 



<Label Content=”{Binding Path=FirstName, Converter={StaticResource stringConverter}}”/> 



 [ValueConversion(typeof (string typeof (string] 



    public class StringToUpperCaseConverter : IValueConverter 

    { 

        public object Convert(object value, Type targetType, object parameter, CultureInfo culture) 

        { 

            string firstName = (string)value; 

            return “FirstName: “ + firstName.ToUpper; 

        } 



        public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture) 

        { 

            return null; 

        } 

    }

(взято отсюда http://flexwinds.wordpress.com/2007/02/15/flex-and-wpf-a-com... )
К тому же все нетипизированно object value.... :crazy:
Да же в ASP.NET-е такое простое преобразование можно выполнить по месту.
И вы говорите, что это упрощает процесс разработки? ;)
 
Только в WPF это не просто полезная фича, примочка к тому что есть, чтобы сделать программирование под Swing проще, а фактически основа на которой построен WPF, что коренным образом влияет на общий дизайн WPF.
  

Кстати, объясните мне сакральный смысл слова "декларативно"
 
что позволяет декларативно определять довольно сложный ГУИ
  

Просто уже от нескольких людей слышал, что, типа, как круто определять что-то декларативно в ASP.NET, в WPF или еще где-то. Насколько я понимаю, в случае ASP.NET и WPF термин "декларативно" отождествлялся с "определением в markup-е". Так за что ж вы так любите этот xml? и так недолюбливаете язык типа C#-а?
Для разметки UI-контролов xml, наверное, действительно, подходит лучше, но для "программной логики" xml ужасен. Те же триггеры, которые я видел в примерах по WPF, выглядят ужасно громоздко. ... Вот еще вспоминается XSLT — технология на любителя ... :smirk: .

freezer

чем тебе XSLT не угодил? :confused:

6yrop

чем тебе XSLT не угодил?
1. Простые вещи часто реализуются нетривиальным кодом.
2. В целом код плохо читаем.

apl13

все-таки прикольней.

6yrop

я тут подумал, да, решение Microsoft-а в лоб и не красивое, но проблема, на самом деле, сложнее, чем может показаться на первый взгляд. Дело в том, что UI-контролы должны автоматически обновляться при изменении свойств бизнес-объектов — такую идеологию исповедует WPF databindiing. Делает ли это Flex, я не в курсе
 
<mx:Label text=”FirstName: {_person.firstName.toUpperCase}“/>

Для автоматического обновления надо из строчки
 
_person.firstName.toUpperCase

выцепить "firstName". А если выражение более сложное?
Не знаю насколько приспособлен язык ActionScript (из Flex) для такого, но C# пока на такое не ориентировался. Наверное, можно подумать использовать лямбда-выражения, но они появились в Framework 3.5, а WPF уже входил в Framework 3.0

6yrop

но они появились в Framework 3.5, а WPF уже входил в Framework 3.0
от Microsoft-а, как от одного поставщика, ждешь целостного согласованного решения. А они как всегда, выпускают экспериментальные версии, и испытывают их на нас. Почему бы не проводить такие эксперименты в каких-нибудь исследовательских лабораториях...

timefim

А если выражение более сложное?
Чето я ничего не понимаю, можно конкретный пример где чего не работает?

6yrop

А если выражение более сложное?
Чето я ничего не понимаю, можно конкретный пример где чего не работает?
не понятно все? или не понятно конкретно то, что ты выделил?
Все работает, но в WPF слишком много кода для такого простого случая.

bastii

Напиши свою библиотеку конверторов.
Чисто кодом в WPF обходится можно, но часто протые вещи на вид в XAML, делаются сложно кодом.

timefim

или не понятно конкретно то, что ты выделил?
То что выделил.
но в WPF слишком много кода для такого простого случая.

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

bastii

правильно, и делай эти конверторы дружелюбными к XAML, чтобы создавать конкретные их экземпляры декларативно

6yrop

 
Напиши свою библиотеку конверторов.
  

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

ребят, просто ЛОЛ :grin: , вы что издеваетесь. Будет время напишу, что своя библиотека, к тому же, конвертеров это плохо.

6yrop

и делай эти конверторы дружелюбными к XAML, чтобы создавать конкретные их экземпляры декларативно
тк объясни что ж вас так притягивает "декларативно" на XAML-е? я там в первом посте спрашивал об этом.

6yrop

замечу, что я выступаю не за то, чтобы все кодом на C# писать. Я за разумный баланс. WPF на мой взгляд начала злоупотреблять XMAL-ом.

aleks058

Сделай свойство FirstNameInUpper и биндись к нему

6yrop

Сделай свойство FirstNameInUpper и биндись к нему
да, я вот как раз ехал в метро, и думал над тем, может все "расчеты" надо засовывать в бизнес-объекты. Но пока я не пришол к окончательному выводу, правильно ли это.

aleks058

Да, меня в БО это засовывать тоже не очень прельщает, но пока ничего лучшего не придумал.
Можно сделать класс PersonForGui, который в конструкторе берет исходного Person и выставляет свойства, предназначенные именно для биндинга.
Обернуть таким образом все бизнес-объекты.
Тут могут возникнуть небольшие заморочки с коллекциями.
Вообще, тут бы кодогенерация неплохо пошла, как и для объектов, мапленных на БД и объектов DTO для передачи меж App-доменами. Они часто очень похожие, но все-таки разные
Еще в GUI пользователи <почему-то> не хотят видеть имя колонки в гриде "PersonNameInUpper", а хотят "User name".

6yrop

случайно наткнулся на статью, где автор тоже понимает суть проблемы. в конце он там предлагает анализировать IL код :D
http://www.codeproject.com/KB/WPF/wpfdatabinding.aspx
P.S. в конце страничке оказалось, что автор из России :)

bastii

Да, меня в БО это засовывать тоже не очень прельщает, но пока ничего лучшего не придумал.Можно сделать класс PersonForGui, который в конструкторе берет исходного Person и выставляет свойства, предназначенные именно для биндинга.Обернуть таким образом все бизнес-объекты.Тут могут возникнуть небольшие заморочки с коллекциями.Вообще, тут бы кодогенерация неплохо пошла, как и для объектов, мапленных на БД и объектов DTO для передачи меж App-доменами. Они часто очень похожие, но все-таки разныеЕще в GUI пользователи <почему-то> не хотят видеть имя колонки в гриде "PersonNameInUpper", а хотят "User name".
похоже на Model-View-ViewModel паттерн, который как раз заточен под WPF binding, насколько я понимаю.

6yrop

Model-View-ViewModel паттерн
да главное придумать название паттерну, и все само сделается :grin: .
Статья малоинформативная, суть можно было изложить в двух преложениях:
XAML то вроде у нас для дизайнеров. Кодеры наваяли бизнес-правила в бизнес- объектах :smirk: И тут неожиданно выясняется, что прога то не работает, оказывается, что еще что-то надо. А что это что-то? И где его место? Не долго думая вводим еще один уровень. Над названием нам тоже лень думать, поэтому остановимся на комбинации слов ViewModel :grin: А уж примеры кода сами напишите...

bastii

ну зачем же так злобно
вообще идея простая — для программиста код ГУИ заканчивается на ViewModel, а XAML уже дело техники (с дизайнером или без — не так важно). Главное, связка ViewModel-XAML-GUI получается тонкой, там уже тестировать нечего, декларативное описание databinding лучше всяких юнит тестов (все остальное за тебя в Майкрософт протестировали).
Оставить комментарий
Имя или ник:
Комментарий: