Во всех WPF фреймворках для контроллеров есть базовый класс, реализующий INotifyPropertyChanged. Например, в Caliburn — это класс PropertyChangedBase. Основная идея таких классов следующая:
Скрытый текст
public class PropertyChangedBase : INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged;
protected virtual void OnPropertyChanged(string propertyName)
{
if (PropertyChanged != null)
{
PropertyChanged.Invoke(this, new PropertyChangedEventArgs(propertyName));
}
}
}
После чего становится несколько легче реализовать свойства наследников такого базого класса. Например:
Скрытый текст
public class MyViewModel : PropertyChangedBase
{
double _myValue;
public double MyValue
{
get
{
return _myValue;
}
set
{
if (_myValue != value)
{
_myValue = value;
OnPropertyChanged("MyValue");
}
}
}
}
Но я нигде не встречал идею... вывернуть эту идею еще дальше. Поясню. Необходимо сделать такой базовый класс:
Скрытый текст
public class ValueViewModel<T> : ViewModel
{
T _value;
public T Value
{
get
{
return _value;
}
set
{
if (!object.Equals(_value, value))
{
_value = value;
OnPropertyChanged("Value");
}
}
}
}
И реализация свойств контроллеров сведется к следующему:
public class MyViewModel : ViewModel
{
public ValueViewModel<double> MyValueViewModel { get; set; }
}
Правда:
<!-- Вместо вот такого -->
<control MyValue="{Binding MyValue}"/>
<!-- Придется писать вот такое -->
<control MyValue="{Binding MyValueViewModel.Value}"/>
Но выгода же очевидна — не надо писать каждый раз get {}; set {}; и загромождать логику ViewModel'и.
Реализовать event'ы ValueChanging и ValueChanged также можно в этом MyValueViewModel.
Здравствуйте, Fortnum, Вы писали: F>Во всех WPF фреймворках для контроллеров есть базовый класс, реализующий INotifyPropertyChanged.
Ой как грусно. Устанавливать базу ради реализации одного единственного события — это F>Но я нигде не встречал идею... вывернуть эту идею еще дальше. Поясню. Необходимо сделать такой базовый класс:
Скрытый текст
F>public class ValueViewModel<T> : ViewModel
F>{
F> T _value;
F> public T Value
F> {
F> get
F> {
F> return _value;
F> }
F> set
F> {
F> if (!object.Equals(_value, value))
F> {
F> _value = value;
F> OnPropertyChanged("Value");
F> }
F> }
F> }
F>}
F>И реализация свойств контроллеров сведется к следующему: F>Но выгода же очевидна — не надо писать каждый раз get {}; set {}; и загромождать логику ViewModel'и. F>Реализовать event'ы ValueChanging и ValueChanged также можно в этом MyValueViewModel. F>Чем это плохо?
Ну вот вы и "придумали" свои собственные свойства зависимостей
Здравствуйте, _FRED_, Вы писали:
_FR>Ой как грусно. Устанавливать базу ради реализации одного единственного события — это
Ну там в конструкторе еще Dispatcher захватывается. А как иначе? Хотя бы то, что класс реализует интерфейс, надо где-то прописывать. А главное, это хоть как-то решает проблему — лучше, чем copy&paste, хотя не так давно я только так и делал — не умер
_FR>Ну вот вы и "придумали" свои собственные свойства зависимостей _FR>Мне больше понравилась такая вот
Ну да Получается, что экземпляр DependencyProperty на стороне View мы моделируем отдельным объектом на стороне ViewModel. Почему нет? Как мне кажется, с точки зрения архитектуры вполне логично "объект-объект" , сокращение синтаксиса идет лишь как следствие, а не как цель. А в приведенном вами примере скоращение синтаксиса все-таки цель. К тому же, если я правильно понял, он применим лишь для проецирования свойств модели на свойства модели вида, что сразу кастрирует саму суть существования промежуточного слоя ViewModel — если перенос пропертей модели во ViewModel в проекте представляет такую трудоемкую задачу, почему бы для некоторых юзкейзов сразу не использовать MVC? По мне, гораздо эффектнее и полезнее выглядит вот этот метод из той же ветки
Кстати, отношение логических слоев ModelView<->View подобно отношению слоев Control<->ControlTemplate Но это не значит, что стоит отказываться от MVVM, а?
If you look at the WPF/SL control architecture, you’ll notice something quite interesting: A Control’s behavior and its View are separated. The platform splits controls into two parts, the Control class (ViewModel) and the ControlTemplate (View). Yes, one reason why MVVM makes sense is because the platform itself is architected in that way. Recalling the previous point: How do you describe the interaction between the Control Class and the ControlTemplate? TemplateBinding. Of coarse, you could venture to build your own MVVM architecture by creating your VMs as descendants of Control and then defining Views as ControlTemplates (please don’t do this). But, there is a better way. DataTemplates extend the same concept by allowing Views over any type of object.
Здравствуйте, Fortnum, Вы писали:
_FR>>Ой как грусно. Устанавливать базу ради реализации одного единственного события — это
F>Ну там в конструкторе еще Dispatcher захватывается. А как иначе?
А сразу от DispatcherObjecta чего бы не унаследоваться тогда
F>Хотя бы то, что класс реализует интерфейс, надо где-то прописывать. А главное, это хоть как-то решает проблему — лучше, чем copy&paste, хотя не так давно я только так и делал — не умер
Да какой там копипаст — несколько простейших строк? Ерунда. Избегать [в разумных пределах] следует дублирования логики, а не строк. А логику можно вынести отдельно, но дв не об этом.
_FR>>Ну вот вы и "придумали" свои собственные свойства зависимостей _FR>>Мне больше понравилась такая вот
идея реализации. F>Ну да Получается, что экземпляр DependencyProperty на стороне View мы моделируем отдельным объектом на стороне ViewModel. Почему нет? Как мне кажется, с точки зрения архитектуры вполне логично "объект-объект" , сокращение синтаксиса идет лишь как следствие, а не как цель. А в приведенном вами примере скоращение синтаксиса все-таки цель.
Синтаксиса чего? Объявления? Вовсе нет. Сокращение синтаксиса — это бенефит. Цель же — устранение того, что не нужно и метаподход к управлению свойствами, командами, коллекциями представления модели.
F>К тому же, если я правильно понял, он применим лишь для проецирования свойств модели на свойства модели вида, что сразу кастрирует саму суть существования промежуточного слоя ViewModel — если перенос пропертей модели во ViewModel в проекте представляет такую трудоемкую задачу, почему бы для некоторых юзкейзов сразу не использовать MVC? По мне, гораздо эффектнее и полезнее выглядит вот этот метод из той же ветки
Если речь о лямбдах — то это всё как раз костыли к сокращению копипаста. А преддложенный метод не позволяет сократить копипаст — он позволяет в корне избавиться от него.
Help will always be given at Hogwarts to those who ask for it.
я использую аналогичнвй велосипед. Есть только одно опасение, такое свойство можно передать куда нибуть в качестве параметра метода и она потеряет связь с родителем.
Ваше решение обладает теми же недостатками, что и все, сделанные людьми решающими подобные задачи. В ряде кейсов, например:
public class MyViewModel : ViewModel
{
public ValueViewModel<double?> MyValueViewModel { get; set; }
}
...
var a = new MyViewModel();
if (a.Value.HasValue)
Console.Write(a.MyValueViewModel.Value.Value);
Выглядит не очень хорошо. Я бился над проблемой ухода от постоянной копипасты всяких OnPropertyChanged более полугода, и пришел к выводу, что единственное решение проблемы — это расширение синтаксический сахар, все остальное имеет побочные эффекты — вы уменьшаете сложность описания свойства, но увеличиваете сложность его использования... Моя реализация с использованием PropertyDescriptor
, особенно наглядно демонстрирует это. Потому берите какой-нить язык, позволяющий расширять свой синтаксис, тот же Nemerle я думаю отлично подойдет, пишите там необходимые расширения и реализуйте слой ViewModel на нем. Что-то типа такого:
Здравствуйте, Visor2004, Вы писали:
V>Ваше решение обладает теми же недостатками, что и все, сделанные людьми решающими подобные задачи. В ряде кейсов, например:
Согласен Value.Value некрасиво. Надо что-нибудь другое придумать будет, .ValueOfProperty.Value, например
V>единственное решение проблемы — это расширение синтаксический сахар, все остальное имеет побочные эффекты — вы уменьшаете сложность описания свойства, но увеличиваете сложность его использования... [skip] Потому берите какой-нить язык, позволяющий расширять свой синтаксис
Да, наверное, это выход. Как в С++ в разных фреймворках, где повсеместно используют маросы #define, для радикального изменения логики класса.
Есть еще один вариант. Не могу, к сожалению, сейчас квалифицированно что-нибудь сказать по нему, но подкоркой чувствую, что должно работать. Это всяческие композитные классы типа прокси. Если не ошибаюсь Unity Application Block от Microsoft позволяет это делать, а еще может быть в новом С# есть подходящий функционал, да и самому реализовать можно. Ведь основная проблема — скомпоновать большой класс из отдельно отлаженных маленьких протомоделек (причем не просто перечень пропертей, но и перенос логики работы этих протомоделек), не переписывая эти модельки заново копипастой в этот большой класс. Если копипастить, можно partial воспользоваться Те же макросы это, по сути, та же композиция, только статическая. Т.е. в рантайме идентичность скомпонованных классов теряется. С прокси мне кажется вариант поинтереснее — например, можно включить один и тот же экземпляр протомодельки в два разных экземпляра ViewModel. Сейчас все то же самое можно сделать, только дерево ViewModel слишком ветвистое получается, что не способствует пониманию читаемого кода, плюс возможные накладки с именами ссылающихся друг на друга моделек.
Здравствуйте, Visor2004, Вы писали:
V>Выглядит не очень хорошо. Я бился над проблемой ухода от постоянной копипасты всяких OnPropertyChanged более полугода, и пришел к выводу, что единственное решение проблемы — это расширение синтаксический сахар, все остальное имеет побочные эффекты — вы уменьшаете сложность описания свойства, но увеличиваете сложность его использования... Моя реализация с использованием PropertyDescriptor
, особенно наглядно демонстрирует это. Потому берите какой-нить язык, позволяющий расширять свой синтаксис, тот же Nemerle я думаю отлично подойдет, пишите там необходимые расширения и реализуйте слой ViewModel на нем. Что-то типа такого:
Оффтоп, конечно, но, господа, я поражаюсь советам в стиле "берите какой-нить язык". Вот прям взяли так всё бросили, крикнули заказчикам, что уходим на полгода в монастырь, откопали за приемлемый уровень зарплаты программеров, владеющих экзотическим языком, и ради чего? Ради одного несчастного события PropertyChanged? Нет уж.
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, Visor2004, Вы писали:
V>>Выглядит не очень хорошо. Я бился над проблемой ухода от постоянной копипасты всяких OnPropertyChanged более полугода, и пришел к выводу, что единственное решение проблемы — это расширение синтаксический сахар, все остальное имеет побочные эффекты — вы уменьшаете сложность описания свойства, но увеличиваете сложность его использования... Моя реализация с использованием PropertyDescriptor
, особенно наглядно демонстрирует это. Потому берите какой-нить язык, позволяющий расширять свой синтаксис, тот же Nemerle я думаю отлично подойдет, пишите там необходимые расширения и реализуйте слой ViewModel на нем. Что-то типа такого: MM>Оффтоп, конечно, но, господа, я поражаюсь советам в стиле "берите какой-нить язык". Вот прям взяли так всё бросили, крикнули заказчикам, что уходим на полгода в монастырь, откопали за приемлемый уровень зарплаты программеров, владеющих экзотическим языком, и ради чего? Ради одного несчастного события PropertyChanged? Нет уж.
А почему поражаетесь? есть люди для которых этот вариант работает, например, я в конце концов так и поступил. Не хотите/не можете использовать, не используйте, никто не заставляет. Я в своем ответе указал на то, что за полгода разных проб так и не удалось найти вариант для C#, который бы удовлетворял критериям простоты использования и простоты декларации свойств, отсюда и рекомендация сменить язык. Более того, я привел ссылку на альтернативный C# подход. Что возмутительного вы находите?
Здравствуйте, Fortnum, Вы писали:
F>Есть еще один вариант. Не могу, к сожалению, сейчас квалифицированно что-нибудь сказать по нему, но подкоркой чувствую, что должно работать. Это всяческие композитные классы типа прокси. Если не ошибаюсь Unity Application Block от Microsoft позволяет это делать, а еще может быть в новом С# есть подходящий функционал, да и самому реализовать можно. Ведь основная проблема — скомпоновать большой класс из отдельно отлаженных маленьких протомоделек (причем не просто перечень пропертей, но и перенос логики работы этих протомоделек), не переписывая эти модельки заново копипастой в этот большой класс. Если копипастить, можно partial воспользоваться Те же макросы это, по сути, та же композиция, только статическая. Т.е. в рантайме идентичность скомпонованных классов теряется. С прокси мне кажется вариант поинтереснее — например, можно включить один и тот же экземпляр протомодельки в два разных экземпляра ViewModel. Сейчас все то же самое можно сделать, только дерево ViewModel слишком ветвистое получается, что не способствует пониманию читаемого кода, плюс возможные накладки с именами ссылающихся друг на друга моделек.
Инфраструктура для таких протомоделек присутствует во фреймворке начиная с первых его версий, по сути вы только что описали взаимосвязь между TypeDescriptor и PropertyDescriptor. Этот подход не облегчает жизни в большинстве кейсов.
Здравствуйте, Visor2004, Вы писали:
V>А почему поражаетесь? есть люди для которых этот вариант работает, например, я в конце концов так и поступил. Не хотите/не можете использовать, не используйте, никто не заставляет. Я в своем ответе указал на то, что за полгода разных проб так и не удалось найти вариант для C#, который бы удовлетворял критериям простоты использования и простоты декларации свойств, отсюда и рекомендация сменить язык. Более того, я привел ссылку на альтернативный C# подход. Что возмутительного вы находите?
Да что-то уж больно много почестей уделяется PropertyChanged
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, Visor2004, Вы писали:
V>>А почему поражаетесь? есть люди для которых этот вариант работает, например, я в конце концов так и поступил. Не хотите/не можете использовать, не используйте, никто не заставляет. Я в своем ответе указал на то, что за полгода разных проб так и не удалось найти вариант для C#, который бы удовлетворял критериям простоты использования и простоты декларации свойств, отсюда и рекомендация сменить язык. Более того, я привел ссылку на альтернативный C# подход. Что возмутительного вы находите? MM>Да что-то уж больно много почестей уделяется PropertyChanged
Ну, наверное, потому что не нравится людям все время писать одинаковый код. А нормального решения сходу придумать нельзя, вот и изголяется кто как может... Но вообще, я заметил, что в сложном софте, при изменении свойства его надо сразу валидировать, обновлять undo стек и еще кучу всякой дряни делать, потому где-то в 60% своих ViewModel я продолжаю использовать кастомный PropertyDescriptor, в котором вся эта логика реализована.
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, Visor2004, Вы писали:
V>>А почему поражаетесь? есть люди для которых этот вариант работает, например, я в конце концов так и поступил. Не хотите/не можете использовать, не используйте, никто не заставляет. Я в своем ответе указал на то, что за полгода разных проб так и не удалось найти вариант для C#, который бы удовлетворял критериям простоты использования и простоты декларации свойств, отсюда и рекомендация сменить язык. Более того, я привел ссылку на альтернативный C# подход. Что возмутительного вы находите? MM>Да что-то уж больно много почестей уделяется PropertyChanged
Классическая задача о предоставлении сквозного функционала, в С# нет нормальных средств для реализации сквозной функциональности, только пара тяжеловесных фреймворков и PostSharp, на который у меня лично аллергия просто, хз почему, наверное, хочется средство из коробки.
Здравствуйте, Visor2004, Вы писали:
V>Инфраструктура для таких протомоделек присутствует во фреймворке начиная с первых его версий, по сути вы только что описали взаимосвязь между TypeDescriptor и PropertyDescriptor. Этот подход не облегчает жизни в большинстве кейсов.
Инфраструктура присутствует, но общепринятое законченное решение отсутствует, либо еще не широко распространено или я до него не дорос Хотя оно сюда так и напрашивается. Если не ошибаюсь, должно быть что-то похожее на Remoting, и поддержка решения на том же уровне.
Здравствуйте, Fortnum, Вы писали:
F>Инфраструктура присутствует, но общепринятое законченное решение отсутствует, либо еще не широко распространено или я до него не дорос Хотя оно сюда так и напрашивается. Если не ошибаюсь, должно быть что-то похожее на Remoting, и поддержка решения на том же уровне.
Она очень широко распространения при написании WinForms компонент.
Здравствуйте, Fortnum, Вы писали:
F>Здравствуйте, Visor2004, Вы писали:
V>>Она очень широко распространения при написании WinForms компонент.
F>Не понял, в стандартном .NET есть готовое решение по динамическому сливанию двух классов в один?
Почитайте здесь. С помощью этого можно реализовывать и более сложные сценарии, чем просто слияние классов.
Здравствуйте, MxMsk, Вы писали:
MM>Оффтоп, конечно, но, господа, я поражаюсь советам в стиле "берите какой-нить язык". Вот прям взяли так всё бросили, крикнули заказчикам, что уходим на полгода в монастырь, откопали за приемлемый уровень зарплаты программеров, владеющих экзотическим языком, и ради чего? Ради одного несчастного события PropertyChanged? Нет уж.
Ну многие так же думают о переходе с C#2 на C#3 (не говоря уже о более позднем) Категорически не воспринимают (не знают ) var, автосвойства и прочие _мелочи_ (о более концептуальных вещах я не говорю). И это тоже можно объяснить, если захотеть
При этом, если раньше всё делалось на раби, то перейти на пайтон или люа проблем почему-то обычно не составляет (ещё один необъяснимый преимущество/недостаток динамических языков?)
Так что "взять какой-нить язык" совсем не сложно — проблему представляет не "язык", ни даже "взять", а то, что "есть". Но есть оно (то что "есть") подходяще, то и "взять" не сложно.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, MxMsk, Вы писали:
MM>>Оффтоп, конечно, но, господа, я поражаюсь советам в стиле "берите какой-нить язык". Вот прям взяли так всё бросили, крикнули заказчикам, что уходим на полгода в монастырь, откопали за приемлемый уровень зарплаты программеров, владеющих экзотическим языком, и ради чего? Ради одного несчастного события PropertyChanged? Нет уж.
_FR>Ну многие так же думают о переходе с C#2 на C#3 (не говоря уже о более позднем) Категорически не воспринимают (не знают ) var, автосвойства и прочие _мелочи_ (о более концептуальных вещах я не говорю). И это тоже можно объяснить, если захотеть
Ну ты сравнил: смена версии языка и смена не только языка, но и парадигмы. Понятно, что можно, если захотеть. Но нужны еще скажем так и экономические обоснования. Я бы с удовольствием сейчас всё бросил и плюхнулся в какой-нибудь другой Nemerle или F#. Вот только деньги я не сам себе плачу и код не для себя пишу
_FR>При этом, если раньше всё делалось на раби, то перейти на пайтон или люа проблем почему-то обычно не составляет (ещё один необъяснимый преимущество/недостаток динамических языков?) _FR>Так что "взять какой-нить язык" совсем не сложно — проблему представляет не "язык", ни даже "взять", а то, что "есть". Но есть оно (то что "есть") подходяще, то и "взять" не сложно.
В моем случае взять и перейти сложно потому, что это не представляет выгоды. Мы на написание свойств моделей тратим в разы меньше времени, чем на весь остальной функционал. Прихожу я значит к начальству и говорю: "Вы знаете, задолбался я писать PropertyChanged. Давайте перепишем проект на другой язык" Да ладно бы язык был более менее снабжен адекватными средствами, так ведь нет, даже долбанный F# и тот плоховато ложиться на WPF. Так что
Здравствуйте, MxMsk, Вы писали:
MM>>>Оффтоп, конечно, но, господа, я поражаюсь советам в стиле "берите какой-нить язык". Вот прям взяли так всё бросили, крикнули заказчикам, что уходим на полгода в монастырь, откопали за приемлемый уровень зарплаты программеров, владеющих экзотическим языком, и ради чего? Ради одного несчастного события PropertyChanged? Нет уж.
_FR>>Ну многие так же думают о переходе с C#2 на C#3 (не говоря уже о более позднем) Категорически не воспринимают (не знают ) var, автосвойства и прочие _мелочи_ (о более концептуальных вещах я не говорю). И это тоже можно объяснить, если захотеть MM>Ну ты сравнил: смена версии языка и смена не только языка, но и парадигмы.
Я привёл причины, что не только смена языка сложности представляет, но даже и смена версии языка (в сторону более новой).
MM>Понятно, что можно, если захотеть.
Я привёл пример того, что даже если "хотим", не всегда "выходит" — пересели, допустим, за 2008, а var-ы так и заменяем на имена типов
То есть я соглашался с тем, что "перейти" на другой язык оч. не просто по самым-самым разным проблемам, ибо даже на новую версию перейти зачастую сложно.
MM>Но нужны еще скажем так и экономические обоснования. Я бы с удовольствием сейчас всё бросил и плюхнулся в какой-нибудь другой Nemerle или F#. Вот только деньги я не сам себе плачу и код не для себя пишу
Мне видится, что экономическая обоснованность — палка о двух концах (обосновать можно и так и сяк). Другое дело, что базинесс более любит прибыль в краткосрочной перспективе И тут аномалия — чем короче, тем лучше
_FR>>При этом, если раньше всё делалось на раби, то перейти на пайтон или люа проблем почему-то обычно не составляет (ещё один необъяснимый преимущество/недостаток динамических языков?) _FR>>Так что "взять какой-нить язык" совсем не сложно — проблему представляет не "язык", ни даже "взять", а то, что "есть". Но есть оно (то что "есть") подходяще, то и "взять" не сложно. MM>В моем случае взять и перейти сложно потому, что это не представляет выгоды. Мы на написание свойств моделей тратим в разы меньше времени, чем на весь остальной функционал. Прихожу я значит к начальству и говорю: "Вы знаете, задолбался я писать PropertyChanged. Давайте перепишем проект на другой язык"
Конечно можно подобрать ещё более неудачную формулировку, что бы начальство задумалось — а не уволить ли тебя вообще Но ведь можно же и так преподнести дело (отбросив технические трудности перехода, о них ниже), что начальство скажет "а что ж с самого начала так не сделали!"
MM>Да ладно бы язык был более менее снабжен адекватными средствами, так ведь нет, даже долбанный F# и тот плоховато ложиться на WPF. Так что
Эт да. Ещё какое-то время этому всему нужно устаканиться.
Но я так и не понял — какова причина "я поражаюсь" — психологическая (нужно учить новое), экономическая (приемлемый уровень зарплаты программеров, владеющих экзотическим языком; деньги я не сам себе плачу) или техническая (плоховато ложиться на WPF)? Для отказа достаточно (на субъективный взгляд) любой одной причины или именно всё вместе ставит крест на возможности? А если бы остались только две какие-нить, их можно было бы преодолеть и "перейти"?
Help will always be given at Hogwarts to those who ask for it.
Эээ..
А написание кодогенерилки в виде решения не рассматриваем?
Дело то на пару часов. Я так для своих нужд (заворачивание DTO в View класс с имплементацией IEditableObject,INotifyPropertyChanged,IDataErrorInfo,ICustomTypeDescriptor итд) уже давно написал (показать не просите, писсано на коленке, стыдно, но работает )
Здравствуйте, Kalina9001, Вы писали:
K>Эээ.. K>А написание кодогенерилки в виде решения не рассматриваем? K>Дело то на пару часов. Я так для своих нужд (заворачивание DTO в View класс с имплементацией IEditableObject,INotifyPropertyChanged,IDataErrorInfo,ICustomTypeDescriptor итд) уже давно написал (показать не просите, писсано на коленке, стыдно, но работает )
я не рассматриваю. Я, по религиозным соображениям, считаю, что кодогенерация для чего угодно, кроме MSIL в рантайме — это зло. Код предназначен для того, чтобы его читал и правил человек, точка. Если нужно формировать код на лету, формируйте на лету, не засоряйте проект с которым работает человек сущностями, которые нужны только машине.
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, Visor2004, Вы писали:
V>>Выглядит не очень хорошо. Я бился над проблемой ухода от постоянной копипасты всяких OnPropertyChanged более полугода, и пришел к выводу, что единственное решение проблемы — это расширение синтаксический сахар, все остальное имеет побочные эффекты — вы уменьшаете сложность описания свойства, но увеличиваете сложность его использования... Моя реализация с использованием PropertyDescriptor
, особенно наглядно демонстрирует это. Потому берите какой-нить язык, позволяющий расширять свой синтаксис, тот же Nemerle я думаю отлично подойдет, пишите там необходимые расширения и реализуйте слой ViewModel на нем. Что-то типа такого: MM>Оффтоп, конечно, но, господа, я поражаюсь советам в стиле "берите какой-нить язык". Вот прям взяли так всё бросили, крикнули заказчикам, что уходим на полгода в монастырь, откопали за приемлемый уровень зарплаты программеров, владеющих экзотическим языком, и ради чего? Ради одного несчастного события PropertyChanged? Нет уж.
Здравствуйте, _FRED_, Вы писали:
_FR>Я привёл пример того, что даже если "хотим", не всегда "выходит" — пересели, допустим, за 2008, а var-ы так и заменяем на имена типов _FR>То есть я соглашался с тем, что "перейти" на другой язык оч. не просто по самым-самым разным проблемам, ибо даже на новую версию перейти зачастую сложно.
Окей
MM>>Но нужны еще скажем так и экономические обоснования. Я бы с удовольствием сейчас всё бросил и плюхнулся в какой-нибудь другой Nemerle или F#. Вот только деньги я не сам себе плачу и код не для себя пишу _FR>Мне видится, что экономическая обоснованность — палка о двух концах (обосновать можно и так и сяк). Другое дело, что базинесс более любит прибыль в краткосрочной перспективе И тут аномалия — чем короче, тем лучше _FR>>>При этом, если раньше всё делалось на раби, то перейти на пайтон или люа проблем почему-то обычно не составляет (ещё один необъяснимый преимущество/недостаток динамических языков?) _FR>>>Так что "взять какой-нить язык" совсем не сложно — проблему представляет не "язык", ни даже "взять", а то, что "есть". Но есть оно (то что "есть") подходяще, то и "взять" не сложно.
Проблему представляет также и готовый код. Выкинуть жалко, а переделывать ли — вопрос.
MM>>В моем случае взять и перейти сложно потому, что это не представляет выгоды. Мы на написание свойств моделей тратим в разы меньше времени, чем на весь остальной функционал. Прихожу я значит к начальству и говорю: "Вы знаете, задолбался я писать PropertyChanged. Давайте перепишем проект на другой язык" _FR>Конечно можно подобрать ещё более неудачную формулировку, что бы начальство задумалось — а не уволить ли тебя вообще Но ведь можно же и так преподнести дело (отбросив технические трудности перехода, о них ниже), что начальство скажет "а что ж с самого начала так не сделали!"
Боюсь, какой язык сейчас не возьми, найти такие аргументы реально сложно, если ты не сам себе начальник.
MM>>Да ладно бы язык был более менее снабжен адекватными средствами, так ведь нет, даже долбанный F# и тот плоховато ложиться на WPF. Так что _FR>Эт да. Ещё какое-то время этому всему нужно устаканиться.
Проблема в том, что оно почти всегда в догоняющих, C# на передовой.
_FR>Но я так и не понял — какова причина "я поражаюсь" — психологическая (нужно учить новое), экономическая (приемлемый уровень зарплаты программеров, владеющих экзотическим языком; деньги я не сам себе плачу) или техническая (плоховато ложиться на WPF)? Для отказа достаточно (на субъективный взгляд) любой одной причины или именно всё вместе ставит крест на возможности? А если бы остались только две какие-нить, их можно было бы преодолеть и "перейти"?
Экономическая. Перспектива использования малораспространенных языков туманна. Ну, т.е. мне как программисту хочется попробовать, но я понимаю, что руководство не так сильно заботит мое творчество, сколько результат и его дальнейшая (этого результата) судьба.
Здравствуйте, Visor2004, Вы писали:
V>я не рассматриваю. Я, по религиозным соображениям, считаю, что кодогенерация для чего угодно, кроме MSIL в рантайме — это зло. Код предназначен для того, чтобы его читал и правил человек, точка. Если нужно формировать код на лету, формируйте на лету, не засоряйте проект с которым работает человек сущностями, которые нужны только машине.
Рубим с плеча? Ну в спор на религиозные темы вступать не буду
Здравствуйте, MxMsk, Вы писали:
_FR>>Но я так и не понял — какова причина "я поражаюсь" — психологическая (нужно учить новое), экономическая (приемлемый уровень зарплаты программеров, владеющих экзотическим языком; деньги я не сам себе плачу) или техническая (плоховато ложиться на WPF)? Для отказа достаточно (на субъективный взгляд) любой одной причины или именно всё вместе ставит крест на возможности? А если бы остались только две какие-нить, их можно было бы преодолеть и "перейти"? MM>Экономическая. Перспектива использования малораспространенных языков туманна. Ну, т.е. мне как программисту хочется попробовать, но я понимаю, что руководство не так сильно заботит мое творчество, сколько результат и его дальнейшая (этого результата) судьба.
То есть если бы [откуда-то] была бы надёжная информация о том, что Nemerle/F#/<X> будет развиваться ближайшие лет десять точно и средства разработки под него будут не в меньшей степени актуальны, чем для C#, то переход на такой язык можно было бы считать обоснованным?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>То есть если бы [откуда-то] была бы надёжная информация о том, что Nemerle/F#/<X> будет развиваться ближайшие лет десять точно и средства разработки под него будут не в меньшей степени актуальны, чем для C#, то переход на такой язык можно было бы считать обоснованным?
это чисто гипотетический вопрос. всеравно никто никогда такого сказать не сможет.
Здравствуйте, Fortnum, Вы писали:
У нас во ViewModelBase защита реализация IDataErrorInfo+INotifyPropertyChanged
public string Name
{
get { return _name; }
set
{
if (_name != value)
{
_name = value;
OnPropertyChanged(() => Name);
}
}
}
От количества кода не избавляет, зато проще рефакторить и всё понятно. Особенно актуально, когда надо при изменении одного поля провалидировать несколько.
Здравствуйте, cvetkov, Вы писали:
_FR>>То есть если бы [откуда-то] была бы надёжная информация о том, что Nemerle/F#/<X> будет развиваться ближайшие лет десять точно и средства разработки под него будут не в меньшей степени актуальны, чем для C#, то переход на такой язык можно было бы считать обоснованным? C>это чисто гипотетический вопрос. всеравно никто никогда такого сказать не сможет.
Например, за шарп и за васик это можно утверждать с вполне разумной долей вероятности.
Есть подорзрения [или надежда ], что через некоторое время такое можно будет сказать и за F# Так вот интересно, на сколько разумной кажется разработка WPF-приложения на F#. С учётом того, что все важнейшие формальные проблемы преодолены.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Ну многие так же думают о переходе с C#2 на C#3 (не говоря уже о более позднем) Категорически не воспринимают (не знают ) var, автосвойства и прочие _мелочи_ (о более концептуальных вещах я не говорю). И это тоже можно объяснить, если захотеть
_FR>При этом, если раньше всё делалось на раби, то перейти на пайтон или люа проблем почему-то обычно не составляет (ещё один необъяснимый преимущество/недостаток динамических языков?)
_FR>Так что "взять какой-нить язык" совсем не сложно — проблему представляет не "язык", ни даже "взять", а то, что "есть". Но есть оно (то что "есть") подходяще, то и "взять" не сложно.
Злостный оффтоп, но все же.
Меня одного раздражает? Он не раби, он руби (здесь)
Здравствуйте, _FRED_, Вы писали:
_FR>То есть если бы [откуда-то] была бы надёжная информация о том, что Nemerle/F#/<X> будет развиваться ближайшие лет десять точно и средства разработки под него будут не в меньшей степени актуальны, чем для C#, то переход на такой язык можно было бы считать обоснованным?
Это резко повысило бы уровень агитации за язык. Только нужно еще кое-что — количество программистов. Сейчас желающих работать на Nemerle и F# найти наверняка очень сложно и дорого. Проекту еще жить.
Здравствуйте, _FRED_, Вы писали:
_FR>Есть подорзрения [или надежда ], что через некоторое время такое можно будет сказать и за F# Так вот интересно, на сколько разумной кажется разработка WPF-приложения на F#. С учётом того, что все важнейшие формальные проблемы преодолены.
Путь в WPF для F# закрыт до тех пор, пока там не появятся public static readonly поля.
Здравствуйте, Fortnum, Вы писали:
V>>Ваше решение обладает теми же недостатками, что и все, сделанные людьми решающими подобные задачи. В ряде кейсов, например: F>Согласен Value.Value некрасиво. Надо что-нибудь другое придумать будет, .ValueOfProperty.Value, например
Можно просто сделать специальную ValueViewModel для Nullable типов.
Здравствуйте, MxMsk, Вы писали:
V>>>Ваше решение обладает теми же недостатками, что и все, сделанные людьми решающими подобные задачи. В ряде кейсов, например: F>>Согласен Value.Value некрасиво. Надо что-нибудь другое придумать будет, .ValueOfProperty.Value, например MM>Можно просто сделать специальную ValueViewModel для Nullable типов.
Так у этой NullableValueViewModel свойство со значением все такое же останется — Value
Здравствуйте, Fortnum, Вы писали:
F>Так у этой NullableValueViewModel свойство со значением все такое же останется — Value
Так это Value будет не Nullable<T>, а просто T. Плюс добавиться свойство HasValue и constraint, что тип T : struct.
Здравствуйте, Fortnum, Вы писали:
F>Но выгода же очевидна — не надо писать каждый раз get {}; set {}; и загромождать логику ViewModel'и.
F>Реализовать event'ы ValueChanging и ValueChanged также можно в этом MyValueViewModel.
F>Чем это плохо?
Та ничем. Очевидно было сразу же, еще во времена WinForms, что обычные св-ва плохо подходят для непосредственного биндинга. Для биндинга лучше использовать абстракцию пина, с довольно сложным поведением. MS тоже до этого доперла, так появились DependecyProperty в WPF. Но для логической развязки, к сложному пину с одной стороны нужен такой же пин с другой стороны. Ты лишь разработал ответный пин.
И даже пофиг детали реализации. Что меня возмутило в WPF с первых же строчек знакомства — это абсолютно нессиметричная схема биндинга. К тому же, сама схема биндинга завязана тупо только на иерархию WPF. Даже компонентная модель как-то поуниверсальнее смотрелась.
Здравствуйте, vdimas, Вы писали:
V>Та ничем. Очевидно было сразу же, еще во времена WinForms, что обычные св-ва плохо подходят для непосредственного биндинга. Для биндинга лучше использовать абстракцию пина, с довольно сложным поведением. MS тоже до этого доперла, так появились DependecyProperty в WPF. Но для логической развязки, к сложному пину с одной стороны нужен такой же пин с другой стороны. Ты лишь разработал ответный пин.
Видимо на такое не пошли из-за излишнего усложнения источника данных. Дернул Linq-ом объекты из базы и всё работает безо всяких пинов.
V>И даже пофиг детали реализации. Что меня возмутило в WPF с первых же строчек знакомства — это абсолютно нессиметричная схема биндинга. К тому же, сама схема биндинга завязана тупо только на иерархию WPF.
Это что значит?
Здравствуйте, MxMsk, Вы писали:
V>>И даже пофиг детали реализации. Что меня возмутило в WPF с первых же строчек знакомства — это абсолютно нессиметричная схема биндинга. К тому же, сама схема биндинга завязана тупо только на иерархию WPF. MM>Это что значит?
Скорее всего, имеется ввиду то, что DependencyProperty может присутствовать лишь у наследника DependencyObject.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Fortnum, Вы писали:
F>>Но выгода же очевидна — не надо писать каждый раз get {}; set {}; и загромождать логику ViewModel'и.
F>>Реализовать event'ы ValueChanging и ValueChanged также можно в этом MyValueViewModel.
F>>Чем это плохо?
V>Та ничем. Очевидно было сразу же, еще во времена WinForms, что обычные св-ва плохо подходят для непосредственного биндинга. Для биндинга лучше использовать абстракцию пина, с довольно сложным поведением. MS тоже до этого доперла, так появились DependecyProperty в WPF. Но для логической развязки, к сложному пину с одной стороны нужен такой же пин с другой стороны. Ты лишь разработал ответный пин.
Я так понимаю что DependencyProperty в первую очередт появились из желания пратачить к произвольному объекту свойства, определяемые контейнером, т.е. для лайоута. А раз уж сделали то можно и для байндинга приспособить дабы не плодить лишних абстракций.
V>И даже пофиг детали реализации. Что меня возмутило в WPF с первых же строчек знакомства — это абсолютно нессиметричная схема биндинга. К тому же, сама схема биндинга завязана тупо только на иерархию WPF. Даже компонентная модель как-то поуниверсальнее смотрелась.
Заточено в первую очередь под xaml, красивой архитектуру байндинга назвать врятли можно, зато не составляет сложностей в использовании в стандартных (= проработанных разработчиками впф) случаях.
V>А вообще, на тему св-в, реализованных в виде в виде легко соединимых м/у собой пинов, размышлял еще черти когда: http://www.rsdn.ru/forum/philosophy/1676773.1.aspx
Есть одно но — очень заморочено, вы вынуждаете под нужды рисовалки реализовывать специальные провайдеры данных, т.е выносите сложность на поверхность. В архитектуре впф берёшь обычный класс и байндишь к контролам — всё просто, понятно и вполне компактно. Код не засоряется лишними деталями байндинга. Сложность зашита глубоко в реализации байндинга и среднестатистический разработчик ничего о ней не знает и знать не должен. Что касается поддержки INotifyPropertyChanged, то меня удивляет почему до сих пор они не придумали языковой поддержки этой функциональности.
Здравствуйте, MxMsk, Вы писали:
MM>Видимо на такое не пошли из-за излишнего усложнения источника данных. Дернул Linq-ом объекты из базы и всё работает безо всяких пинов.
Ага, "само работает" .
В этом случае пины создаются в рантайм через рефлексию во время биндинга. И еще ищутся одноименные PropNameChanging/PropNameChanged через рефлексию, даже если их нет и нам оно не надо. Т.е. сам процесс биндинга очень дорогой получается. И там такая каша внутри, надо признать, что ручки бы по плечи отрубить бы.
Кстати, DependecyProperty тоже не обязательно было как экземпляры отдельных объектов (пинов то бишь) разрабатывать. Принципиально схема этого не требует, даже с учетом всех политик роутинга. Ведь можно было как в компонентной модели — все описать атрибутами, а в рантайме создавать экземпляры пинов по описаниям атрибутов. ИМХО, этот синтаксический кошмар в стиле С++ был сделан исключительно ради легковесности операции биндинга хотя бы с одной стороны (самой насыщенной подробностями). И то, в С++ синтаксически удобней бы вышло и-за встроенных в язык указателей на мемберы . Это я намекаю на необходимость упоминать требуемые мемберы при описании DependencyProperty через строковые литералы, что затрудняет рефакторинг.
И хотя мне не нравится как это сделано, но это ход в правильном направлении. Проблема там образовалось лишь от того, что забыли отделить мух от котлет. Продолжаем.
ИМХО, вот этот вариант с автоматическим созданием ответных пинов-источников сигнала через рефлексию по всяким name convention я бы оставил как fall-back вариант биндинга для бедных. А для общего случая предоставил бы удобные и внятные хелперы, чтобы свои объекты сразу можно было наделять специальными пинами-источниками сигналов. И все это универсально бы сделать в рамках донета, а не WPF-only. Тогда биндинг мог бы быть по-настоящему легковесным. И в своем прикладном коде это все запросто могло бы быть использовано, то бишь возможно было простое подключение get одного св-ва к set другого. В общем, по ссылке в предыдущем сообщении об этом чуть подробнее с примерами.
А то сейчас такая полезная возможность соединения св-в объектов доступна только для WPF и WCF компонентов, да еще и дизайн попахивает инженерным идиотизмом. Поясню. Мало того, что обе модели не совместимы и ни одна из них и близко не претендует на универсальность, так они еще умудрились намешать в кучу несколько совершенно ортогональные вещей: это собственно биндинг + поддержка его декларативности для работы через XAML + собственно dependency парадигма, реализованная (о нет!!!) в базовом классе.
В общем, слабовато у них с инженерией, двойка за дизайн... хоть AVK был когда-то со мной крайне не согласен с этой оценкой при рассмотрении WPF сразу по его выходу...
V>>К тому же, сама схема биндинга завязана тупо только на иерархию WPF. MM>Это что значит?
Что в WCF, например, свой DependecnyObject, а если хочу разработать просто компонент, который работал бы и там и там, то тут уже придется слегка изворачиваться.
Здравствуйте, Aviator, Вы писали:
A>Я так понимаю что DependencyProperty в первую очередт появились из желания пратачить к произвольному объекту свойства, определяемые контейнером, т.е. для лайоута. А раз уж сделали то можно и для байндинга приспособить дабы не плодить лишних абстракций.
Похожая модель работала в componentModel без dependency property, реализованная "расширителями". Куда как более правильный дизайн, ибо подразумевает комбинаторный подход к расширению набора св-в и даже ресолвит конфликты этих одноименных расширяемых св-в.
Там мотив был несколько другой.
A>Заточено в первую очередь под xaml, красивой архитектуру байндинга назвать врятли можно, зато не составляет сложностей в использовании в стандартных (= проработанных разработчиками впф) случаях.
V>>А вообще, на тему св-в, реализованных в виде в виде легко соединимых м/у собой пинов, размышлял еще черти когда: http://www.rsdn.ru/forum/philosophy/1676773.1.aspx
A>Есть одно но — очень заморочено, вы вынуждаете под нужды рисовалки реализовывать специальные провайдеры данных, т.е выносите сложность на поверхность. В архитектуре впф берёшь обычный класс и байндишь к контролам — всё просто, понятно и вполне компактно. Код не засоряется лишними деталями байндинга. Сложность зашита глубоко в реализации байндинга и среднестатистический разработчик ничего о ней не знает и знать не должен. Что касается поддержки INotifyPropertyChanged, то меня удивляет почему до сих пор они не придумали языковой поддержки этой функциональности.
Здравствуйте, vdimas, Вы писали:
V>Что в WCF, например, свой DependecnyObject, а если хочу разработать просто компонент, который работал бы и там и там, то тут уже придется слегка изворачиваться.
Вы с WWF не путаете случайно?
Здравствуйте, Codechanger, Вы писали:
V>>Что в WCF, например, свой DependecnyObject, а если хочу разработать просто компонент, который работал бы и там и там, то тут уже придется слегка изворачиваться. C>Вы с WWF не путаете случайно?
Здравствуйте, vdimas, Вы писали:
V>Ага, "само работает" . V>В этом случае пины создаются в рантайм через рефлексию во время биндинга. И еще ищутся одноименные PropNameChanging/PropNameChanged через рефлексию, даже если их нет и нам оно не надо. Т.е. сам процесс биндинга очень дорогой получается. И там такая каша внутри, надо признать, что ручки бы по плечи отрубить бы.
Как оно внутри — неважно. "Само работает" — это значит, что работает без нашего активного участия
V>Кстати, DependecyProperty тоже не обязательно было как экземпляры отдельных объектов (пинов то бишь) разрабатывать. Принципиально схема этого не требует, даже с учетом всех политик роутинга. Ведь можно было как в компонентной модели — все описать атрибутами, а в рантайме создавать экземпляры пинов по описаниям атрибутов. ИМХО, этот синтаксический кошмар в стиле С++ был сделан исключительно ради легковесности операции биндинга хотя бы с одной стороны (самой насыщенной подробностями). И то, в С++ синтаксически удобней бы вышло и-за встроенных в язык указателей на мемберы . Это я намекаю на необходимость упоминать требуемые мемберы при описании DependencyProperty через строковые литералы, что затрудняет рефакторинг.
Как ты собираешься описывать атрибутами обработчики изменения, валидации и корректировки значений свойств? DependencyProperty — это не только Binding.
Да, строковые литералы раздражают.
V>И хотя мне не нравится как это сделано, но это ход в правильном направлении. Проблема там образовалось лишь от того, что забыли отделить мух от котлет. Продолжаем. V>ИМХО, вот этот вариант с автоматическим созданием ответных пинов-источников сигнала через рефлексию по всяким name convention я бы оставил как fall-back вариант биндинга для бедных. А для общего случая предоставил бы удобные и внятные хелперы, чтобы свои объекты сразу можно было наделять специальными пинами-источниками сигналов. И все это универсально бы сделать в рамках донета, а не WPF-only. Тогда биндинг мог бы быть по-настоящему легковесным. И в своем прикладном коде это все запросто могло бы быть использовано, то бишь возможно было простое подключение get одного св-ва к set другого. В общем, по ссылке в предыдущем сообщении об этом чуть подробнее с примерами.
V>А то сейчас такая полезная возможность соединения св-в объектов доступна только для WPF и WCF компонентов, да еще и дизайн попахивает инженерным идиотизмом. Поясню. Мало того, что обе модели не совместимы и ни одна из них и близко не претендует на универсальность, так они еще умудрились намешать в кучу несколько совершенно ортогональные вещей: это собственно биндинг + поддержка его декларативности для работы через XAML + собственно dependency парадигма, реализованная (о нет!!!) в базовом классе. V>В общем, слабовато у них с инженерией, двойка за дизайн... хоть AVK был когда-то со мной крайне не согласен с этой оценкой при рассмотрении WPF сразу по его выходу...
Разница в сущности в том, что ты предлагаешь сделать Binding глобальной фичей .Net, а MS его сделала фичей только WPF.
V>>>К тому же, сама схема биндинга завязана тупо только на иерархию WPF. MM>>Это что значит? V>Что в WCF, например, свой DependecnyObject, а если хочу разработать просто компонент, который работал бы и там и там, то тут уже придется слегка изворачиваться.
Так и Binding — механизм WPF.
Много букв очень . Для меня, как практика, вполне приемлем текущий дизайн. Да, несколько муторно реализовывать свойства, но с другой стороны не так уж и много времени и главное — по силам даже начинающему разработчику, что немаловажно для UI фреймворка. Да, было бы приятно если бы на уровне языка была поддержка INotifiyPropertyChanged, но именно приятно, необходимости не вижу. Если избавиться от строковых констант, как я описал выше, то проблема с рефакторингом стоит не так остро, так что жить вполне можно.
Здравствуйте, MxMsk, Вы писали:
V>>Ага, "само работает" . V>>В этом случае пины создаются в рантайм через рефлексию во время биндинга. И еще ищутся одноименные PropNameChanging/PropNameChanged через рефлексию, даже если их нет и нам оно не надо. Т.е. сам процесс биндинга очень дорогой получается. И там такая каша внутри, надо признать, что ручки бы по плечи отрубить бы.
MM>Как оно внутри — неважно. "Само работает" — это значит, что работает без нашего активного участия
Я же говорю, вариант "биндинга для бедных" никто не отменял. Очень хорошо такой вариант работает в статическом биндинге. Но совершенно неприемлим, если мы используем, например, паттерн State, и довольно часто прыгаем по состояниям. Тут уже придется весь биндинг ручками, в случае отсутствия некоего единого callback-интерфейса для всех состояний (что порой удобно)... а могли бы использовать готовый универсальный механизм биндинга.
V>>Кстати, DependecyProperty тоже не обязательно было как экземпляры отдельных объектов (пинов то бишь) разрабатывать. Принципиально схема этого не требует, даже с учетом всех политик роутинга. Ведь можно было как в компонентной модели — все описать атрибутами, а в рантайме создавать экземпляры пинов по описаниям атрибутов. ИМХО, этот синтаксический кошмар в стиле С++ был сделан исключительно ради легковесности операции биндинга хотя бы с одной стороны (самой насыщенной подробностями). И то, в С++ синтаксически удобней бы вышло и-за встроенных в язык указателей на мемберы . Это я намекаю на необходимость упоминать требуемые мемберы при описании DependencyProperty через строковые литералы, что затрудняет рефакторинг. MM>Как ты собираешься описывать атрибутами обработчики изменения, валидации и корректировки значений свойств?
MS с самого начала использует некий name convention относительно событий валидирования св-в. Добавить в этот convention всё что надо.
Опять же, я не агитирую за этот путь, лишь демонстрирую разворот в сторону явного описания биндинга в С++ стиле. И утверждаю, что пойдя по этому пути, очень отличному от аттрибутов, необходимо было доработать декомпозицию. Т.е., если мы спустились с атрибутов до объектов, то необходимо было придерживаться популярных принципов ООП.
В случае атрибутов у нас неплохая декомпозиция идет изначально, как оно обычно бывает при слабой связанности и декларативном описании, и которое в свою очередь — суть композиция ранее определенных фич.
MM>DependencyProperty — это не только Binding.
Золотые слова! Только увидеть это надо было ДО разработки, а не после.
MM>Разница в сущности в том, что ты предлагаешь сделать Binding глобальной фичей .Net, а MS его сделала фичей только WPF.
И еще фичей WWF, и до этого в ComponentModel, которую WinForms юзает, и которая наполовину (со стороны источника данных) задействована и сейчас в WPF/WWF.
V>>Что в WCF, например, свой DependecnyObject, а если хочу разработать просто компонент, который работал бы и там и там, то тут уже придется слегка изворачиваться. MM>Так и Binding — механизм WPF.
Во-первых нет, а во-вторых, конкретно в биндинге WPF нет ничего, специфичного для GUI. Вообще ничего.
Здравствуйте, vdimas, Вы писали:
V>Я же говорю, вариант "биндинга для бедных" никто не отменял. Очень хорошо такой вариант работает в статическом биндинге. Но совершенно неприемлим, если мы используем, например, паттерн State, и довольно часто прыгаем по состояниям. Тут уже придется весь биндинг ручками, в случае отсутствия некоего единого callback-интерфейса для всех состояний (что порой удобно)... а могли бы использовать готовый универсальный механизм биндинга.
Круто, но я не понял. Чего не хватает?
V>>>Кстати, DependecyProperty тоже не обязательно было как экземпляры отдельных объектов (пинов то бишь) разрабатывать. Принципиально схема этого не требует, даже с учетом всех политик роутинга. Ведь можно было как в компонентной модели — все описать атрибутами, а в рантайме создавать экземпляры пинов по описаниям атрибутов. ИМХО, этот синтаксический кошмар в стиле С++ был сделан исключительно ради легковесности операции биндинга хотя бы с одной стороны (самой насыщенной подробностями). И то, в С++ синтаксически удобней бы вышло и-за встроенных в язык указателей на мемберы . Это я намекаю на необходимость упоминать требуемые мемберы при описании DependencyProperty через строковые литералы, что затрудняет рефакторинг. MM>>Как ты собираешься описывать атрибутами обработчики изменения, валидации и корректировки значений свойств?
V>MS с самого начала использует некий name convention относительно событий валидирования св-в. Добавить в этот convention всё что надо.
Этот механизм абсолютно не обязателен к использованию. У нас в проекте вообще такого нет. И потом, тот же рефакторинг превратиться в сущий ад... А уж как вызывать валидацию или корректировку из кода, совсем непонятно.
V>Опять же, я не агитирую за этот путь, лишь демонстрирую разворот в сторону явного описания биндинга в С++ стиле. И утверждаю, что пойдя по этому пути, очень отличному от аттрибутов, необходимо было доработать декомпозицию. Т.е., если мы спустились с атрибутов до объектов, то необходимо было придерживаться популярных принципов ООП. V>В случае атрибутов у нас неплохая декомпозиция идет изначально, как оно обычно бывает при слабой связанности и декларативном описании, и которое в свою очередь — суть композиция ранее определенных фич.
MM>>DependencyProperty — это не только Binding. V>Золотые слова! Только увидеть это надо было ДО разработки, а не после. MM>>Разница в сущности в том, что ты предлагаешь сделать Binding глобальной фичей .Net, а MS его сделала фичей только WPF. V>И еще фичей WWF, и до этого в ComponentModel, которую WinForms юзает, и которая наполовину (со стороны источника данных) задействована и сейчас в WPF/WWF.
Ну, тут только гадать. Вообще, привязка данных не такая уж простая вещь. Взять хотя-бы тот же Dispatcher. Как его вписать в ComponentModel? А ведь он нужен, чтобы нормально разруливать многопоточность. В-общем, я не настолько углубленно знаю исходники .Net, чтобы уверено утверждать, якобы MS ничего не стоило сделать Binding повсеместным.
V>>>Что в WCF, например, свой DependecnyObject, а если хочу разработать просто компонент, который работал бы и там и там, то тут уже придется слегка изворачиваться. MM>>Так и Binding — механизм WPF. V>Во-первых нет, а во-вторых, конкретно в биндинге WPF нет ничего, специфичного для GUI. Вообще ничего.
Я не о концепции привязки данных вообще, а о реализации, в которой Binding — это не средство BCL, а средство WPF.
MM>Это резко повысило бы уровень агитации за язык. Только нужно еще кое-что — количество программистов. Сейчас желающих работать на Nemerle и F# найти наверняка очень сложно и дорого. Проекту еще жить.
Поспорю фактом. На мои первые отзывы о Nemerle в реальном проекте в асю несколько человек ломанулось с вопросом есть ли вакансии, и просьбой стучать сразу как будут. Так что думаю пока язык интересен и нов — желающих писать на нём найти сравнительно легко, и квалификация этих желающих таки выше чем обычных прогеров.
Здравствуйте, MxMsk, Вы писали:
MM>Ну, тут только гадать. Вообще, привязка данных не такая уж простая вещь.
Разве? Мне казалось, тут давно все понятно было еще со времен COM и MFC. И практически ничего нового именно в плане привязки данных мы не увидели. Мы увидели подвижки по декларативности и по построенной на этой декларативности параметризуемости отображения юзверских и не только типов данных. Но! Мухи отдельно, котлеты — отдельно. Декларативностью занимается совершенно отдельный механизм, который использует имеющиеся механизмы биндинга для реализации своих фич. Т.е. сам биндинг "понятия не имеет" как, кто и для чего его использует.
MM>Взять хотя-бы тот же Dispatcher. Как его вписать в ComponentModel?
Никак. Это тоже отдельная вещь совершенно. Задача биндинга состоит в распространении сигнала от источника к подписчикам. Для этого надо:
— подписаться на изменения данных источника
— сообщать об изменении подписчикам.
Диспатчер мог бы быть как прокси от источника к подписчикам, и тут сценариев могло бы быть довольно много. Доставка событий — это вообще задача интересная сама по себе. Чего только диспатчеры COM/OLE стоят, работающие абсолютно прозрачно для скриптов и программ на VB в свое время . Но в дотнете все как-то напрямую и топорно. Диспатчер сделан в виде подменяемого "плагина" и даны несколько его реализаций по некоему жесткому АПИ. И это уже при наличии более одной работающей системы маршаллинга вызовов в дотнете. В общем, тот самый "фатальный недостаток", проявляющийся среди разрозненных команд разработчиков внутри одной конторы.
MM>А ведь он нужен, чтобы нормально разруливать многопоточность. В-общем, я не настолько углубленно знаю исходники .Net, чтобы уверено утверждать, якобы MS ничего не стоило сделать Binding повсеместным.
Поверь, они на биндинге и диспатчинге собаку съели. Другой такой же развитой инфраструктуры как COM/DCOM/OLE/ActiveX/COM+, вообще никто никогда не делал. По количеству реализованных сценариев и обыгранных мелочей, и по общей эффективности никакая CORBA и рядом не валялась (ближайший конкурент, отстававший лет на 15-20). Просто выглядит так, будто сейчас биндинг/диспатчинг писали совсем другие люди, без всего этого предварительного опыта. ИМХО, даже в исходники не потрудились заглянуть, хотя они им доступны.
Здравствуйте, Aviator, Вы писали:
A>Ну и разрыв мозга, почти ничего не понял .
Спрашивай, не стесняйся. Если дейтсивтельно интересно, можно любые упоминания уточнить до конкретных типов из дотнетных либ. Просто предполагалось, что собеседники и так в курсе.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Aviator, Вы писали:
A>>Ну и разрыв мозга, почти ничего не понял .
V>Спрашивай, не стесняйся. Если дейтсивтельно интересно, можно любые упоминания уточнить до конкретных типов из дотнетных либ. Просто предполагалось, что собеседники и так в курсе.
А практический смысл? Какой бы плохой или хорошой не был wpf, это всё равно mainstream для ui в windows. И что касается байндинга имхо нааамного продвинутее винформсов.
Здравствуйте, Aviator, Вы писали:
V>>Спрашивай, не стесняйся. Если дейтсивтельно интересно, можно любые упоминания уточнить до конкретных типов из дотнетных либ. Просто предполагалось, что собеседники и так в курсе. A>А практический смысл? Какой бы плохой или хорошой не был wpf, это всё равно mainstream для ui в windows. И что касается байндинга имхо нааамного продвинутее винформсов.
С каких это пор оно mainstream? У меня только одно установленное приложение использует WPF, да и то, это приложение уж очень узконишевое.
ИМХО, WPF уйдет в небытие, уступив нишу сервелату. А последний гораздо более "вещь в себе". Да и по мультимедиа возможностям почему-то обгоняет WPF. Хотя сервелат смотрелся как эксперимент в первых версиях, но сегодня всё выглядит так, будто 2 продукта меняются местами. Теперь WPF идет как полигон для обкатки решений и идей для сервелата.
Здравствуйте, vdimas, Вы писали:
V>ИМХО, WPF уйдет в небытие, уступив нишу сервелату. А последний гораздо более "вещь в себе". Да и по мультимедиа возможностям почему-то обгоняет WPF. Хотя сервелат смотрелся как эксперимент в первых версиях, но сегодня всё выглядит так, будто 2 продукта меняются местами. Теперь WPF идет как полигон для обкатки решений и идей для сервелата.
Здравствуйте, vdimas, Вы писали:
V>С каких это пор оно mainstream? У меня только одно установленное приложение использует WPF, да и то, это приложение уж очень узконишевое.
Вопрос времени, слишком много написано на формсах.
V>ИМХО, WPF уйдет в небытие, уступив нишу сервелату. А последний гораздо более "вещь в себе". Да и по мультимедиа возможностям почему-то обгоняет WPF. Хотя сервелат смотрелся как эксперимент в первых версиях, но сегодня всё выглядит так, будто 2 продукта меняются местами. Теперь WPF идет как полигон для обкатки решений и идей для сервелата.
А разве это не один и тот же продукт для разных environment?
Здравствуйте, Aviator, Вы писали:
V>>С каких это пор оно mainstream? У меня только одно установленное приложение использует WPF, да и то, это приложение уж очень узконишевое. A>Вопрос времени, слишком много написано на формсах.
На формсах приложения легковеснее гораздо, запускаются в 2-5 раз быстрее. И потому на них продолжают писать аж бегом.
A>А разве это не один и тот же продукт для разных environment?
На первый взгляд близнецы-братья, но лишь на первый. Удивительно не то, что сервелат не имеет всех возможностей "полновесного" WPF, а то, что последний тоже не имеет многих интересных и важных фич сервелата. Я бы сказал — ключевых фич, требуемых для мультимедиа-приложений. Именно наличие этих ключевых фич в сервелате и наталкивает на мысли, что приоритет у него повыше будет. Предполагаю, что как только в сервелате будут реализованы все фичи WPF, последний умрет за ненадобностью.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Aviator, Вы писали:
V>>>С каких это пор оно mainstream? У меня только одно установленное приложение использует WPF, да и то, это приложение уж очень узконишевое. A>>Вопрос времени, слишком много написано на формсах.
V>На формсах приложения легковеснее гораздо, запускаются в 2-5 раз быстрее. И потому на них продолжают писать аж бегом.
Вопрос времени. Было дело, когда спорили зачем писать на с++, когда есть си.
A>>А разве это не один и тот же продукт для разных environment?
V>На первый взгляд близнецы-братья, но лишь на первый. Удивительно не то, что сервелат не имеет всех возможностей "полновесного" WPF, а то, что последний тоже не имеет многих интересных и важных фич сервелата. Я бы сказал — ключевых фич, требуемых для мультимедиа-приложений. Именно наличие этих ключевых фич в сервелате и наталкивает на мысли, что приоритет у него повыше будет. Предполагаю, что как только в сервелате будут реализованы все фичи WPF, последний умрет за ненадобностью.
Во первых, в студию эти ключевые фичи. А во вторых, если подумать, то если в области десктопа ms твёрдо на ногах, в вебе на данный момент его позиции вызывают сомнения. Так что ожидаемо, что первым делом ms пиарит нововведение в вебе.
Здравствуйте, Aviator, Вы писали:
A>Во первых, в студию эти ключевые фичи.
Я же упомянул — мультимедиа возможности. Более конкретно — мультимедиа устройства ввода, по которым большой кукиш в WPF. Наверно из-за наличия недоогрызка — Managed DirectX, который неюзабелен совершенно для чего-то более менее серьезного.
A>А во вторых, если подумать, то если в области десктопа ms твёрдо на ногах, в вебе на данный момент его позиции вызывают сомнения. Так что ожидаемо, что первым делом ms пиарит нововведение в вебе.
Сервелат не только для веба двигается, вот в чем основной прикол. Так же как XNA — не только для X-Box.
Интересно, когда два проекта сольются в экстазе?
Здравствуйте, vdimas, Вы писали:
V>Я же упомянул — мультимедиа возможности. Более конкретно — мультимедиа устройства ввода, по которым большой кукиш в WPF.
Какие еще "мультимедиа устройства ввода"? В чем кукиш?
V>Наверно из-за наличия недоогрызка — Managed DirectX, который неюзабелен совершенно для чего-то более менее серьезного.
Причем здесь Managed DirectX???
Здравствуйте, cvetkov, Вы писали:
C>я использую аналогичнвй велосипед. Есть только одно опасение, такое свойство можно передать куда нибуть в качестве параметра метода и она потеряет связь с родителем.
Правильно мыслишь. Только этот момент и препятствует озвученной практике. Однако, сию практику не так сложно обложить парой хелперов и получить массу преимуществ. Например, модель св-ва может содержать и владельца, то бишь сам объект.
И реализовать это легковесно (то бишь без постоянного хранения ссылки на родителя во всех св-вах) можно примерно так:
// определяем базовый класс-хелперclass PropertyChangedBase<TOwner> {
...
// value view model proxypublic struct ValueHelper<T> {
ValueViewModel<T> _target;
// proxy to eventpublic event EventHandler<T> ValueChanged {
add { _target.ValueChanged += value; }
remove { _target.ValueChanged -= value; }
}
// proxy to valuepublic T Value { get {return _target.Value; } set { _Target.Value = value;} }
// чтобы связь не потерятьpublic TOwner Owner { get; private set; }
}
...
}
// используемclass SomeObjType : PropertyChangedBase<SomeObjType> {
ValueViewModel<double> _value;
public ValueHelper<double> Value { get { return new ValueHelper<double>(this, _value); } }
}
А если подходить более формально ко всему этому делу, то такие хелперы вовсе не нужны. Т.е. любую связь достаточно представить некоей абстракцией (схематично):
struct Bind<T> {
public IPropertyBag Src;
public PropertyDef<T> SrcProp;
public IPropertyBag Dst;
public PropertyDef<T> DstProp;
}
interface IPropertyBag {
T this[PropertyDef<T> prop] { get; set; }
void OnPropertyChanged(PropertyDef<T> prop);
}
Соответственно, описание пропертей — статическое.
И гораздо удобнее получается OnPropertyChanged(), в сравнении с вариантом, когда аргумент в виде строки (имени св-ва).
Угу, схема напоминает DependencyProperty, только симметричную, и с той разницей, что парадигма dependency на этом уровне абстракции вовсе не при чем.
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, vdimas, Вы писали:
V>>Я же упомянул — мультимедиа возможности. Более конкретно — мультимедиа устройства ввода, по которым большой кукиш в WPF. MM>Какие еще "мультимедиа устройства ввода"? В чем кукиш?
Приплызд. А какие ты знаешь?
V>>Наверно из-за наличия недоогрызка — Managed DirectX, который неюзабелен совершенно для чего-то более менее серьезного. MM>Причем здесь Managed DirectX???
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Aviator, Вы писали:
A>>Во первых, в студию эти ключевые фичи.
V>Я же упомянул — мультимедиа возможности. Более конкретно — мультимедиа устройства ввода, по которым большой кукиш в WPF. Наверно из-за наличия недоогрызка — Managed DirectX, который неюзабелен совершенно для чего-то более менее серьезного.
Это ключевые возможности? Да действительно, без них гуи библиотекой совершенной невозможно пользоваться . WPF пока что очень молодая и очень сырая, недоделанная либа. Вспомните первый формс, который писался как вобщем то обёрткой над апи. А тут совершенная другая парадигма, принципиально отличающаяся от классического гуи фреймворка. Вполне понятно, что спешат и маркетинг опережает техническую часть. Допилят, но не сразу .
A>>А во вторых, если подумать, то если в области десктопа ms твёрдо на ногах, в вебе на данный момент его позиции вызывают сомнения. Так что ожидаемо, что первым делом ms пиарит нововведение в вебе.
V>Сервелат не только для веба двигается, вот в чем основной прикол. Так же как XNA — не только для X-Box. V>Интересно, когда два проекта сольются в экстазе?
А собственно почему это XNA должен быть только для x-box?
Здравствуйте, Aviator, Вы писали:
V>>Я же упомянул — мультимедиа возможности. Более конкретно — мультимедиа устройства ввода, по которым большой кукиш в WPF. Наверно из-за наличия недоогрызка — Managed DirectX, который неюзабелен совершенно для чего-то более менее серьезного. A>Это ключевые возможности? Да действительно, без них гуи библиотекой совершенной невозможно пользоваться .
Пользоваться можно. Но вот фишка в том, что реализовать в сервелате то, чего нет в WPF смогут многие, а вот наоборот — слишком трудоемко.
A>WPF пока что очень молодая и очень сырая, недоделанная либа. Вспомните первый формс, который писался как вобщем то обёрткой над апи. А тут совершенная другая парадигма, принципиально отличающаяся от классического гуи фреймворка. Вполне понятно, что спешат и маркетинг опережает техническую часть. Допилят, но не сразу .
Второй винформс вышел через пару лет после первого, а тут уже 4 года прошло. Дело не в сырости, а в отсутствии интереса производителя к вложению ресурсов в проект. И это видно невооруженным взглядом. Отсюда такие невеселые мысли. Да и механизм рендеринга в WPF на сегодня — более чем спорный. Вот тут подробнее проходился: http://www.rsdn.ru/forum/flame.comp/3965533.1.aspx
A>А собственно почему это XNA должен быть только для x-box?
Изначально так позиционировался. А сейчас пришли к пониманию того, что нужна единая мультимедиа-платформа, которая походила бы как десктопам, так и "маленьким" устройствам (у которых мощщи сегодня, как у десктопов 7-летней давности). В WPF/сервелате хорошо с контролами, но убого с аудио/видео и 3D, в XNA наоборот. Я лишь вижу, что в общую модель сервелат имеет шансы вписаться быстрее WPF...
Когда я говорил о мультимедиа вводе/выводе, имел ввиду аудио и видео и всю сопутствующую инфраструктуру.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Aviator, Вы писали:
V>>>Я же упомянул — мультимедиа возможности. Более конкретно — мультимедиа устройства ввода, по которым большой кукиш в WPF. Наверно из-за наличия недоогрызка — Managed DirectX, который неюзабелен совершенно для чего-то более менее серьезного. A>>Это ключевые возможности? Да действительно, без них гуи библиотекой совершенной невозможно пользоваться .
V>Пользоваться можно. Но вот фишка в том, что реализовать в сервелате то, чего нет в WPF смогут многие, а вот наоборот — слишком трудоемко.
Тема была про датабайндинг в типичном среднестатистическом десктоп приложении, в итоге вы упорно сваливаетесь в узкоспециализированные вопросы мультимедиа. Датабайндинг сделан вполне прилично, винформсы рядом не стояли. Мультимедийную часть допилят со временем, сомневаюсь что это ключевое направление для wpf. А силвер, как красивость для веба и оппонент флэшу, должен в первую очередь иметь хорошую поддержку мультимедиа. Приоритеты разные.
A>>WPF пока что очень молодая и очень сырая, недоделанная либа. Вспомните первый формс, который писался как вобщем то обёрткой над апи. А тут совершенная другая парадигма, принципиально отличающаяся от классического гуи фреймворка. Вполне понятно, что спешат и маркетинг опережает техническую часть. Допилят, но не сразу .
V>Второй винформс вышел через пару лет после первого, а тут уже 4 года прошло. Дело не в сырости, а в отсутствии интереса производителя к вложению ресурсов в проект. И это видно невооруженным взглядом. Отсюда такие невеселые мысли. Да и механизм рендеринга в WPF на сегодня — более чем спорный. Вот тут подробнее проходился: http://www.rsdn.ru/forum/flame.comp/3965533.1.aspx
Ну собственно и что, как это доказывает что wpf — барахло?. Вы посмотрите исходники винформсов, так такое что понаписано, что удивительно как оно вообще работает.
Здравствуйте, Aviator, Вы писали:
A>Мультимедийную часть допилят со временем, сомневаюсь что это ключевое направление для wpf.
Не допилят никогда. И как бы почему не ключевое направление? Разве вся эта цветоградиентная раскраска и анимация не часть мультимедиа как такового?
A>А силвер, как красивость для веба и оппонент флэшу, должен в первую очередь иметь хорошую поддержку мультимедиа. Приоритеты разные.
Просто сильверлайт требует свой фреймворк. И для этого фреймворка существуют интересные требования, которые очень быстро сделают его более востребованным, чем "десктопный" вариант. Понимаешь, все те возможности, которые нужны современным приложениям, могут быть доступны и из сервелатных вариантов. Вроде бы отличие лишь в уровне безопасности... Но посмотри на новую модель безопасности в Vista и выше. Уже даже десктопные приложения не могут (без специальной подкрутки политик) писать в собственные папки внутри ProgramFiles. Понимаешь, модель безопасность хоста потихоньку подбирается к модели общей модели безопасности приложений, что для веба, что для инсталлированных локально. И сильверлайт эти требования осблуживает изначально. А это означает лишь одно: когда модели будут друг другу соответсвовать, в отдельном десктопном фреймворке не будет нужды. Как и в WPF.
A>Ну собственно и что, как это доказывает что wpf — барахло?. Вы посмотрите исходники винформсов, так такое что понаписано, что удивительно как оно вообще работает.
Нормально там работает, по крайне мере для стандартных контролов. Куча абракадабры с дизайнерами, но это не проблема WinForms, а проблема выбранной сериализации в код. И это дало приличный бенефит в виде времени загрузки окна. Но не об этом речь. Речь о том, что десктопный фреймворк на сегодня таков по природе, что unmanaged вызовы крайне дороги, поэтому рендеринг в WPF обложился целым нехилым промежуточным слоем лишь для того, чтобы не вызывать методы интерфейсов COM/DirectX из managed части. И эта вынужденная прослойка обрубает целый спектр потенциальных мультимедиа-возможностей WPF, ибо ограничена возможностями нерасширяемого нативного "плеера" сериализованных WPF-сцен.
Здравствуйте, vdimas, Вы писали:
V>Не допилят никогда. И как бы почему не ключевое направление? Разве вся эта цветоградиентная раскраска и анимация не часть мультимедиа как такового?
Ваще-то нет. То что свалено на Медиа плеер — и есть мультимедия.
A>>А силвер, как красивость для веба и оппонент флэшу, должен в первую очередь иметь хорошую поддержку мультимедиа. Приоритеты разные.
V>Понимаешь, модель безопасность хоста потихоньку подбирается к модели общей модели безопасности приложений, что для веба, что для инсталлированных локально. И сильверлайт эти требования осблуживает изначально. А это означает лишь одно: когда модели будут друг другу соответсвовать, в отдельном десктопном фреймворке не будет нужды. Как и в WPF.
А вот этого не будет никогда. Опыт Виста показал что нельзя вечно защищать OS от программ. Поэтому в W7 несколько ослабили политику. Но это не касается программ с низким elevation коим является сильверлайт и скрипты полученные из гадких источников.
A>>Ну собственно и что, как это доказывает что wpf — барахло?. Вы посмотрите исходники винформсов, так такое что понаписано, что удивительно как оно вообще работает.
V>Нормально там работает, по крайне мере для стандартных контролов. Куча абракадабры с дизайнерами, но это не проблема WinForms, а проблема выбранной сериализации в код. И это дало приличный бенефит в виде времени загрузки окна. Но не об этом речь. Речь о том, что десктопный фреймворк на сегодня таков по природе, что unmanaged вызовы крайне дороги, поэтому рендеринг в WPF обложился целым нехилым промежуточным слоем лишь для того, чтобы не вызывать методы интерфейсов COM/DirectX из managed части. И эта вынужденная прослойка обрубает целый спектр потенциальных мультимедиа-возможностей WPF, ибо ограничена возможностями нерасширяемого нативного "плеера" сериализованных WPF-сцен.
1. Ваще-то есть у меня подозрение что причина была совершенно другой. Вывод на экран в WPF размазан по всему времени жизни программы. У него нет WM_PAINT е.t.c. И подобные экзерцисы были сделаны только для того, чтобы локализовать время сброса графики на экран.
2. Desktop и игры — это совершенно разные рынки, и совершенно разные особенности. Расширение возможностей десктопа и выход за ограничения GUI отнюдь не значит что мы будем строить realtime картинки. Для десктопов это не нужно.
Здравствуйте, GlebZ, Вы писали:
GZ>1. Ваще-то есть у меня подозрение что причина была совершенно другой. Вывод на экран в WPF размазан по всему времени жизни программы. У него нет WM_PAINT е.t.c. И подобные экзерцисы были сделаны только для того, чтобы локализовать время сброса графики на экран.
Да пофиг там время сброса. Рендерится все в back surface, затем bitblt на DC и все. Просто WPF изначально рассчитан на рендеринг огромного кол-во примитивов, и дерганье COM-интерфейсов напрямую превратило бы все это в слайд-шоу. WM_PAINT, кстати, есть, так же как и все остальные сообщения из этой области, только они не в юзверском треде проходят, а в треде оконного хоста. Без WM_PAINT и BeginPaint/EndPaint на экран выводилось бы много лишнего из буфера DirectX. Мы же в оконном режиме GUI крутим, а не полноэкранном.
GZ>2. Desktop и игры — это совершенно разные рынки, и совершенно разные особенности. Расширение возможностей десктопа и выход за ограничения GUI отнюдь не значит что мы будем строить realtime картинки. Для десктопов это не нужно.
Станет нужно, как только эти возможности перейдут из области почти недосягаемости среднему индусу до вполне применимых.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Fortnum, Вы писали:
F>> if (!object.Equals(_value, value)) GZ>Вот эта строчка может создавать проблемы
Ну это у автора наверное для примера.
Всегда можно поменять на
if (Comparer<T>.Default.Compare(_value, value) != 0)
Здравствуйте, vdimas, Вы писали:
V>>>Я же упомянул — мультимедиа возможности. Более конкретно — мультимедиа устройства ввода, по которым большой кукиш в WPF. MM>>Какие еще "мультимедиа устройства ввода"? В чем кукиш? V>Приплызд. А какие ты знаешь?
Устройства ввода? Клавиатура, например
Давай уже конкретику — какие такие "мультимедиа устройства ввода", нужные для GUI Framework, есть в Silverlight, по которым "большой кукиш в WPF"?
Интересно же...
V>>>Наверно из-за наличия недоогрызка — Managed DirectX, который неюзабелен совершенно для чего-то более менее серьезного. MM>>Причем здесь Managed DirectX??? V>Все ясно, время потратил зря.
Зря не зря. А за написанное надо бы ответить.
Здравствуйте, MxMsk, Вы писали:
MM>Давай уже конкретику — какие такие "мультимедиа устройства ввода", нужные для GUI Framework, есть в Silverlight, по которым "большой кукиш в WPF"? MM>Интересно же...
MM>Там нет ничего по делу. Тоже "круче, чем Армяни" только больше букв.
Ну я же с коллегой разговариваю или как? Т.е. самостоятельно сравнить набор классов для мультимедиа в сервелате и WPF нам не под силу? Тогда смысл участвовать в этом обсуждении?
Добавлю чуток.
GZ>А вот этого не будет никогда. Опыт Виста показал что нельзя вечно защищать OS от программ. Поэтому в W7 несколько ослабили политику.
Набор политик остался тот же, и механизм связки безопасности и калбека в юзер лендовский message box такой же, просто дефолтные установки чуть другие. Что не мешает делать их фактически произвольными. Я себе в win7 полтики подкрутил, т.к. даже сейчас сложновато пользоваться мне, как разработчику, ибо под сеть пишем, и вопросы системы малость достают. В Висте до этого делал аналогично, т.е. по мне — одно и то же.
GZ>Но это не касается программ с низким elevation коим является сильверлайт и скрипты полученные из гадких источников.
Это все тоже настраивается. Фишка в том, что сервелат — это в первую очередь разрабатываемая с чистого листа новая дотнет-платформа. Чуть более закрытая, но и заведомо более безопасная. Мне тут вспоминается как WinNT со своей новой моделью безопасности cожрала в итоге Win95/98, дав свое ядро и для десктопного варианта. Уж очень похожие сценарии. По мере усложнения фреймворков будет все сложнее поддерживать конкурирующие ветки. Остаться должен только один (С). И дураку понятно "кто" это будет.
Здравствуйте, vdimas, Вы писали:
V>Ну я же с коллегой разговариваю или как? Т.е. самостоятельно сравнить набор классов для мультимедиа в сервелате и WPF нам не под силу? Тогда смысл участвовать в этом обсуждении?
Коллега, ну приведи несколько примеров. Чего заставлять другого перелопачивать неизвестный Framework в поисках разницы?
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, vdimas, Вы писали:
V>>Ну я же с коллегой разговариваю или как? Т.е. самостоятельно сравнить набор классов для мультимедиа в сервелате и WPF нам не под силу? Тогда смысл участвовать в этом обсуждении? MM>Коллега, ну приведи несколько примеров. Чего заставлять другого перелопачивать неизвестный Framework в поисках разницы?
Ну хотя бы чтобы увидеть степень заинтересованности собеседника, чтобы понимать что не просто так траля-ля разводим.
Конкретней, поищи в сервелатных сборках что там насчет захвата видео. И попробуй отыскать тоже самое в WPF. Найти крайне легко по именам неймспейсов. Легче, чем тебе кажется. Хотя, то, что оно тебе и даром не надо, было понятно еще 5 постов назад.
Здравствуйте, Fortnum, Вы писали:
F>Чем это плохо?
Подниму тему! Мне нравится этот вариант, но вот возник затык с добавлением таких фичей, как callback на изменение и, допустим, валидацию. Есть ли варианты? Возможно я пропустил их при чтении темы
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, Fortnum, Вы писали:
F>>Чем это плохо? MM>Подниму тему! Мне нравится этот вариант, но вот возник затык с добавлением таких фичей, как callback на изменение и, допустим, валидацию. Есть ли варианты? Возможно я пропустил их при чтении темы
Ответ в способе связки конкретного экземпляра ValueViewModel с делегатом, который будет валидировать значение. Чем проще способ связки, тем проще и нагляднее. В рамках предложенной идеологии можно таким образом:
interface IViewModel<T> : INotifyPropertyChanged, IEditableObject
{
Func<T, bool> Validator { get; }
}
class ValueViewModel<T> : IViewModel<T>
{
public Func<T, bool> Validator { get; private set; }
}
public class MyViewModel : ViewModel
{
public MyViewModel()
{
MyValueViewModel = new ValueViewModel<double> { Validator = a => a > 0 };
}
public IViewModel<double> MyValueViewModel { get; private set; }
}
Здравствуйте, Visor2004, Вы писали:
V>Ответ в способе связки конкретного экземпляра ValueViewModel с делегатом, который будет валидировать значение. Чем проще способ связки, тем проще и нагляднее. В рамках предложенной идеологии можно таким образом:
Это первое, что приходит в голову, конечно. Но такой вариант неплох, только если метод не делает ничего с экземпляром. А если делает, то каждое создание объекта — создание делегата. Боюсь дорого.
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, Visor2004, Вы писали:
V>>Ответ в способе связки конкретного экземпляра ValueViewModel с делегатом, который будет валидировать значение. Чем проще способ связки, тем проще и нагляднее. В рамках предложенной идеологии можно таким образом: MM>Это первое, что приходит в голову, конечно. Но такой вариант неплох, только если метод не делает ничего с экземпляром. А если делает, то каждое создание объекта — создание делегата. Боюсь дорого.
никто не мешает наплодить гору примерно таких классов, но не думаю, что это будет сильно дешевле, все равно создаются ссылки на делегаты:
Здравствуйте, MxMsk, Вы писали:
MM>Оффтоп, конечно, но, господа, я поражаюсь советам в стиле "берите какой-нить язык". Вот прям взяли так всё бросили, крикнули заказчикам, что уходим на полгода в монастырь, откопали за приемлемый уровень зарплаты программеров, владеющих экзотическим языком, и ради чего? Ради одного несчастного события PropertyChanged? Нет уж.
А зачем на пол года то? Можно и без отрыва от стужи.
К тому же человек дело сказал. Можно же не весь проект на другом языке делать, а только то, что на этом совсем криво выходит. Ну, а результат уже юзать в своем проекте. Со временем процент умного кода (и соответственно кода на более мощном языке) неминуемо увеличится. Не враги же вы себе? Но тогда у вас и отношение изменится.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _FRED_, Вы писали:
_FR>При этом, если раньше всё делалось на раби, то перейти на пайтон или люа проблем почему-то обычно не составляет (ещё один необъяснимый преимущество/недостаток динамических языков?)
Скорее здесь дело не в динамике, а в том, что за ними нет мегакорпорации. Меняя Питон на Луа или Луа на Руби ты меняешь один язык на другой. А вот меняя C# на Nemerle ты почему-то думаешь, что меняешь мощь корпорации на поделки гиктов.
_FR>Так что "взять какой-нить язык" совсем не сложно — проблему представляет не "язык", ни даже "взять", а то, что "есть".
Проблема заключается в собственных страхах и привычках. Если сделать шаг, то оказывается, что проблемы то не так уж и страшны.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, MxMsk, Вы писали:
MM>Проблему представляет также и готовый код. Выкинуть жалко, а переделывать ли — вопрос.
А зачем выкидывать и переделывать? Можно же просто писать новый код по другому и переделывать только то, что и так переделывается.
MM>Экономическая. Перспектива использования малораспространенных языков туманна. Ну, т.е. мне как программисту хочется попробовать, но я понимаю, что руководство не так сильно заботит мое творчество, сколько результат и его дальнейшая (этого результата) судьба.
А руководство не думало, что используя более мощный язык команда поднимет свою производительность и повысит качество конечного продукта? Ты же не ради игрушек хочешь "попробовать"? Ты же видишь реальные преимущества (а их ой как больше чем кажется на первый взгляд).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, MxMsk, Вы писали:
MM>Это резко повысило бы уровень агитации за язык. Только нужно еще кое-что — количество программистов. Сейчас желающих работать на Nemerle и F# найти наверняка очень сложно и дорого. Проекту еще жить.
Все с точностью до наоборот. Найти желающих очень легко. И уровень их очень высокий. А вот найти работу очень сложно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
_FR>>При этом, если раньше всё делалось на раби, то перейти на пайтон или люа проблем почему-то обычно не составляет (ещё один необъяснимый преимущество/недостаток динамических языков?)
R>Злостный оффтоп, но все же. R>Меня одного раздражает? Он не раби, он руби (здесь)
Так и знал, что дисскуссии по поводу люа и пайтона не будет .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
_FR>>При этом, если раньше всё делалось на раби, то перейти на пайтон или люа проблем почему-то обычно не составляет (ещё один необъяснимый преимущество/недостаток динамических языков?) VD>Скорее здесь дело не в динамике, а в том, что за ними нет мегакорпорации. Меняя Питон на Луа или Луа на Руби ты меняешь один язык на другой. А вот меняя C# на Nemerle ты почему-то думаешь, что меняешь мощь корпорации на поделки гиктов.
Я был юы несказанно рад взять "поделку гиков", если бы она удовлетворяла моему чувству прекрасного Пока что "у гиков" я, к большому сожелению, вижу только интересные идеи не пригодные, на мой какой-никакой взгляд, к жизни в реальном мире. Роль "корпорации" в этом, наверное, есть: "корпорация" может позволить себе решить сделать то, что мне нравится и сделать то, что мне "почти" нравится. А "гики" почему-то не могут увидеть преимуществ свойств перед полями У "корпорации" не редко хромает реализация в мелочах. Сильно реже, но всё же, хромают задумки в крупных масштабах. Это даёт достаточно уверенное чувство контроля на тем, что происходит.
_FR>>Так что "взять какой-нить язык" совсем не сложно — проблему представляет не "язык", ни даже "взять", а то, что "есть". VD>Проблема заключается в собственных страхах и привычках. Если сделать шаг, то оказывается, что проблемы то не так уж и страшны.
Не страх не привычки в динамических языках обычно не мешают Там решают как раз "языковые фишки" (коих в немерле более чем) и библиотеки (коих в немерле не меньше чем в шарпе, а, даже, больше). А вот чего-то всё-таки не хватает. ИМХО, вы ищите проблему не там (не в "корпорациях" проблема). Примите, что сам по себе "Немерль" не нужен, он интересен именно в рамках существующей развиваемой большими деньгами платформой и отказ от обычаев платформы — это щаг в сторону, тогда как _ничто_ не мешает шагать в ногу.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, VladD2, Вы писали:
VD>Все с точностью до наоборот. Найти желающих очень легко. И уровень их очень высокий. А вот найти работу очень сложно.
Ну давай прикинем. Допустим, я нахожу этих профессионалов высокого уровня. Сколько? Ну, пускай 20 человек. Кто из них согласиться решать те задачи, которые нужно мне? Ну, допустим половина кандидатов согласится. Продолжаем. Эти 10 человек все сплошь — профессионалы высокого уровня. Согласятся они стать джуниорами, в лучшем случае синьорами? И вот тебе еще 5 человек убежало. Оставшиеся согласились, а тут им — профессионалам высокого уровня — приходит предложение от конкурентов. "Интересная работа на Немерле!". И осталось два человека, которые вписались в бюджет синьорами... И так далее... А на другой стороне — сотни программеров C# начального и среднего уровня, готовые браться за любые задачи ради роста. Так что не все так просто.
Здравствуйте, MxMsk, Вы писали:
MM>Ну давай прикинем. Допустим, я нахожу этих профессионалов высокого уровня. Сколько? Ну, пускай 20 человек.
Зачем тебе 20? В прочем, по фигу.
MM>Кто из них согласиться решать те задачи, которые нужно мне?
Все согласятся, если достойную зарплату дашь. Так что ты предлагай. Уверен, что отбоя от работников не будет.
За хорошую зарплату сам пойду к тебе и "подниму" какой-нить средний проектик, если доверите.
MM>Ну, допустим половина кандидатов согласится. Продолжаем. Эти 10 человек все сплошь — профессионалы высокого уровня. Согласятся они стать джуниорами, в лучшем случае синьорами?
Да ты пойми, им по фиг как называться. Плати деньги (ну скажем от 80 штук деревянных, если в Москве работа) и будут к тебе толпы стоять.
MM>И вот тебе еще 5 человек убежало.
Куда же они убегут то? Ты не понял, что предлагаешь (гипотетически) весьма уникальное предложение?
MM>Оставшиеся согласились, а тут им — профессионалам высокого уровня — приходит предложение от конкурентов. "Интересная работа на Немерле!". И осталось два человека, которые вписались в бюджет синьорами... И так далее... А на другой стороне — сотни программеров C# начального и среднего уровня, готовые браться за любые задачи ради роста. Так что не все так просто.
Это ты какую-то утопию нарисовал. На самом деле твои джуниоры реально сложных задач решить будут не в силах. Идея закидывания шапками таков в нашем деле плохо работает.
Убежать от тебя людям еще долгое время будет не куда, по известным тебе причинам. Все точно так же боятся как ты (чего, сами не знают).
Но факт остается фактом. Команда немерлистов из 5-10 человек поднимет тебе за годик проект который силами 40 джуниров с приставленными к ним архитекторами вы будете решать 3 года и с огромной вероятностью завалите.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
_FR>>Я был юы несказанно рад взять "поделку гиков", если бы она удовлетворяла моему чувству прекрасного VD>Ты пока что только теоретизируешь и ищешь причины чтобы не пробовать. Так что не стоит оправдывать свой настрой реальными факторами.
Несомненно, вам виднее
Help will always be given at Hogwarts to those who ask for it.