Здравствуйте, Cyberax, Вы писали:
C>>>И вот мне её не хочется делать. G>>И для этого надо говродить немалый фреймвок. G>>Изобретение веосипедов за деньги заказчика в наше время не самое хорошее занятие. C>Мои проблемы не решаются простыми способами...
То что ваши поблемы не решаются простыми способами я даже не сомневаюсь.
А вот код который вы пишите вполне мог бы быть проще раз в 10 при использовании соотвествуюещего подхода.
C>>>В WPF ты привязываешь контролы (которые могут быть даже неименованы) к данным модели. Я делаю наоборот — привязываю данные (возможно неименованых) формул к именованым контролам. Противоположный подход. G>>И как при таком подходе тестировать логику UI? C>А накой её тестировать? GUI должны тестировать живые люди.
C>Автоматически тестировать надо формулы, чему моя система только способствует.
Состояния модели тестировать уже не надо? Зашибись...
G>>И для этого надо говродить немалый фреймвок. G>>Изобретение веосипедов за деньги заказчика в наше время не самое хорошее занятие. C>Мои проблемы не решаются простыми способами...
Угу, поэтому вы себе и того больше усложняете жизнь. Индусологика. тьфу
G>>>> OnPropertyChanging("Money"); G>>>> OnPropertyChanging("MoneyPercent"); C>>>Сломается. G>>Как сломается? C>Лень объяснять.
Еще бы. Это в стандартах местных линухоидов — сначала ляпнуть чушь, потом съехать с темы "мне лень объяснять"... тьфу
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>>> OnPropertyChanging("Money"); G>>>> OnPropertyChanging("MoneyPercent"); C>>>Сломается. G>>Как сломается? C>Лень объяснять.
C>>>Сломается, если шаг инкремента поля ввода процентов (спиннера) будет меньше минимального шага. G>>Какого инкремента? G>>Там текстбоксы. C>Ну попробуй для спиннера сделать.
Теперь понял к чему ты клонишь.
При UpdateSourceTrigger=PropertyChanged проперти апдейтится, а новое значение не считывается, чтобы избежать зацикливания (например изменение A меняет B, изменение B при этом меняет A).
Для текстбоксов по умолчанию UpdateSourceTrigger=LostFocus и считываение нового значения происходит при потере фокуса, а не при изменении.
Для сайдера лечится очень простым обработчиком ValueChanged:
private void Slider_ValueChanged(object sender, RoutedPropertyChangedEventArgs<double> e)
{
var slider = sender as Slider;
slider.GetBindingExpression(Slider.ValueProperty).UpdateTarget();
}
C>>>Ну и у меня всё это уложится примерно в 5 строк прикладного кода G>>Ага, и 180 кб фреймворка. C>У меня таких полей около 5 тысяч штук. Будем считать экономию?
Мне вас очень жаль ваших пользователей если у вас столько полей в программе.
Здравствуйте, gandjustas, Вы писали:
C>>Ну попробуй для спиннера сделать. G>Теперь понял к чему ты клонишь. G>При UpdateSourceTrigger=PropertyChanged проперти апдейтится, а новое значение не считывается, чтобы избежать зацикливания (например изменение A меняет B, изменение B при этом меняет A).
Это тоже, особенно если в этом участвует ещё три-четыре контрола.
G>
G>private void Slider_ValueChanged(object sender, RoutedPropertyChangedEventArgs<double> e)
G>{
G> var slider = sender as Slider;
G> slider.GetBindingExpression(Slider.ValueProperty).UpdateTarget();
G>}
G>
А теперь учти, что у тебя оно иногда будет "непередвигаемым", так как некоторые состояния слайдера будут невалидными.
G>>>Ага, и 180 кб фреймворка. C>>У меня таких полей около 5 тысяч штук. Будем считать экономию? G>Мне вас очень жаль ваших пользователей если у вас столько полей в программе.
Не в одной форме, естественно. С количеством ничего не сделать, это не мы придумываем эти формы.
Здравствуйте, kuj, Вы писали:
kuj>Заметь, что при этом эти же джависты рассказывают нам басни о том, что под джава больше библиотек и что это дотнетчики изобретают велосипеды, либо копируют их из джава.
kuj>Двойные стандарты на лицо.
Ну, в последнем флейме, например, речь шла об open-source библиотеках, которые можно было бы использовать на Mono без опаски лицензионного преследования со стороны МС. WPF к таким библиотекам не относится
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Ну попробуй для спиннера сделать. G>>Теперь понял к чему ты клонишь. G>>При UpdateSourceTrigger=PropertyChanged проперти апдейтится, а новое значение не считывается, чтобы избежать зацикливания (например изменение A меняет B, изменение B при этом меняет A). C>Это тоже, особенно если в этом участвует ещё три-четыре контрола.
Неважно. Этот эффект распространятеся только на активный контрол.
G>>
G>>private void Slider_ValueChanged(object sender, RoutedPropertyChangedEventArgs<double> e)
G>>{
G>> var slider = sender as Slider;
G>> slider.GetBindingExpression(Slider.ValueProperty).UpdateTarget();
G>>}
G>>
C>А теперь учти, что у тебя оно иногда будет "непередвигаемым", так как некоторые состояния слайдера будут невалидными.
Визуально слайдер на эти состояния не попадает.
G>>>>Ага, и 180 кб фреймворка. C>>>У меня таких полей около 5 тысяч штук. Будем считать экономию? G>>Мне вас очень жаль ваших пользователей если у вас столько полей в программе. C>Не в одной форме, естественно. С количеством ничего не сделать, это не мы придумываем эти формы.
Я уверен что и с количеством можно что-то сделать если применить ViewModel и повторно используемые DataTemplate.
Кроме того можно применить генерацию темплейтов по метаданным.
Сильно сомневаюсь что даже половину из этих 5 тысяч контролов надо описывать в xaml.
G>>>private void Slider_ValueChanged(object sender, RoutedPropertyChangedEventArgs<double> e)
G>>>{
G>>> var slider = sender as Slider;
G>>> slider.GetBindingExpression(Slider.ValueProperty).UpdateTarget();
G>>>}
G>>>
C>>А теперь учти, что у тебя оно иногда будет "непередвигаемым", так как некоторые состояния слайдера будут невалидными. G>Визуально слайдер на эти состояния не попадает.
Почему? Вполне может. Просто это как раз первая реальная проблема была, с которой я столкнулся. В некоторых случаях модель может быть неконсистентной, и надо приостановить передачу данных до восстановления целостности.
А при восстановлении целостности тоже интересные результаты — несколько контролов одновременно могут решить пересчитаться, что вызывает проблемы с зависимостями. И это даже не у одного меня встречается —
G>>>Мне вас очень жаль ваших пользователей если у вас столько полей в программе. C>>Не в одной форме, естественно. С количеством ничего не сделать, это не мы придумываем эти формы. G>Я уверен что и с количеством можно что-то сделать если применить ViewModel и повторно используемые DataTemplate.
Они заметно разные.
G>Кроме того можно применить генерацию темплейтов по метаданным. G>Сильно сомневаюсь что даже половину из этих 5 тысяч контролов надо описывать в xaml.
Кое-что там общее, но много различий. Это формы налоговой и страховой отчётности, для всех 50 штатов в США и десятка крупных страховых компаний. Хорошо хоть, что мы купили готовые формы в виде XMLей с описанием полей и таблицы расчёта налогов.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>>>
G>>>>private void Slider_ValueChanged(object sender, RoutedPropertyChangedEventArgs<double> e)
G>>>>{
G>>>> var slider = sender as Slider;
G>>>> slider.GetBindingExpression(Slider.ValueProperty).UpdateTarget();
G>>>>}
G>>>>
C>>>А теперь учти, что у тебя оно иногда будет "непередвигаемым", так как некоторые состояния слайдера будут невалидными. G>>Визуально слайдер на эти состояния не попадает. C>Почему? Вполне может. Просто это как раз первая реальная проблема была, с которой я столкнулся. В некоторых случаях модель может быть неконсистентной, и надо приостановить передачу данных до восстановления целостности.
Это уже похоже на выдумывание проблем на ходу.
Зачем модели быть неконсистентной, если нам ничего не стоит постоянно поддерживать её конситентность?
Кстати приведенный мной код, вместе с последним добавлением, полностью решает описанную вами проблему с двумя контролави редактирования бабла и процентов.
Если вы продолжаете считать что WPF не подходит для ваших задач можете попробоавть другую проблему описать, которую вам не удалось решить.
C>А при восстановлении целостности тоже интересные результаты — несколько контролов одновременно могут решить пересчитаться, что вызывает проблемы с зависимостями. И это даже не у одного меня встречается —
Да вот видимо только у вас одно это всречается. Вам Qbit уже написал почему вынос зависимостей во viewmodel помогает.
Вкратце объясняю: у вас не будет бешеных зависимостей между контролами.
G>>>>Мне вас очень жаль ваших пользователей если у вас столько полей в программе. C>>>Не в одной форме, естественно. С количеством ничего не сделать, это не мы придумываем эти формы. G>>Я уверен что и с количеством можно что-то сделать если применить ViewModel и повторно используемые DataTemplate. C>Они заметно разные.
Да ну, напишите мне в личку чем отличаются друг от друга все 5000, я даже почитаю.
G>>Кроме того можно применить генерацию темплейтов по метаданным. G>>Сильно сомневаюсь что даже половину из этих 5 тысяч контролов надо описывать в xaml. C>Кое-что там общее, но много различий. Это формы налоговой и страховой отчётности, для всех 50 штатов в США и десятка крупных страховых компаний. Хорошо хоть, что мы купили готовые формы в виде XMLей с описанием полей и таблицы расчёта налогов.
Ну так вам и флаг в руки, напишите код который парсит xml и создает нужные контролы.
Здравствуйте, gandjustas, Вы писали:
C>>Почему? Вполне может. Просто это как раз первая реальная проблема была, с которой я столкнулся. В некоторых случаях модель может быть неконсистентной, и надо приостановить передачу данных до восстановления целостности. G>Это уже похоже на выдумывание проблем на ходу. G>Зачем модели быть неконсистентной, если нам ничего не стоит постоянно поддерживать её конситентность?
Это невозможно. Например, ты редактируешь форму, поправил что-то в одном поле — другое поле ушло в отрицательное значение, что для него невозможно.
Чтобы восстановить положительное значение — тебе надо поправить третье поле. В ряде случаев можно автоматически корректировать третье поле, в ряде случаев нельзя.
Ещё есть шутки с граничными условиями. Например, у нас есть два режима вычисления при значении N ползунка N>50 и N<50. Мы подводим к 49 и из-за округления он устанавливается на 51, а обратное вычисление скидывает его на 50, которое округляется до 49, которое снова устанавливается в 51 и т.д.
G>Кстати приведенный мной код, вместе с последним добавлением, полностью решает описанную вами проблему с двумя контролави редактирования бабла и процентов.
Я её слишком упростил.
G>Если вы продолжаете считать что WPF не подходит для ваших задач можете попробоавть другую проблему описать, которую вам не удалось решить.
Сложно просто модельный пример сделать, где всякие тонкие эффекты видно было бы.
C>>А при восстановлении целостности тоже интересные результаты — несколько контролов одновременно могут решить пересчитаться, что вызывает проблемы с зависимостями. И это даже не у одного меня встречается — G>Да вот видимо только у вас одно это всречается. Вам Qbit уже написал почему вынос зависимостей во viewmodel помогает. G>Вкратце объясняю: у вас не будет бешеных зависимостей между контролами.
А не деться от них никуда. Такие зависимости в формулах.
G>>>Я уверен что и с количеством можно что-то сделать если применить ViewModel и повторно используемые DataTemplate. C>>Они заметно разные. G>Да ну, напишите мне в личку чем отличаются друг от друга все 5000, я даже почитаю.
Нет, контролы сами не отличаются. Их там что-то всего штук 10 видов. Отличаются вычисления, привязанные к ним.
Если ты представляешь себе что такое налоговая отчётность, то должно быть понятно.
C>>Кое-что там общее, но много различий. Это формы налоговой и страховой отчётности, для всех 50 штатов в США и десятка крупных страховых компаний. Хорошо хоть, что мы купили готовые формы в виде XMLей с описанием полей и таблицы расчёта налогов. G>Ну так вам и флаг в руки, напишите код который парсит xml и создает нужные контролы.
Так написали. Создать контролы и показать их — это фигня, мелочь. Проблема что с ними дальше делать.
Здравствуйте, Cyberax, Вы писали:
C>Это невозможно. Например, ты редактируешь форму, поправил что-то в одном поле — другое поле ушло в отрицательное значение, что для него невозможно.
В WPF есть ещё такая штука как value coercion. Правила согласования значений можно передать через CoerceValueCallback, afair. И это помимо средств собственно валидации, которыми можешь просто запретить/ограничить неверный ввод.
C>А не деться от них никуда. Такие зависимости в формулах.
Эти зависимости не должны разруливаться в терминах гуёвых контролов. Иначе ты не сможешь заменить морду при необходимости (например, нацепить веб-интерфейс).
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Почему? Вполне может. Просто это как раз первая реальная проблема была, с которой я столкнулся. В некоторых случаях модель может быть неконсистентной, и надо приостановить передачу данных до восстановления целостности. G>>Это уже похоже на выдумывание проблем на ходу. G>>Зачем модели быть неконсистентной, если нам ничего не стоит постоянно поддерживать её конситентность? C>Это невозможно. Например, ты редактируешь форму, поправил что-то в одном поле — другое поле ушло в отрицательное значение, что для него невозможно. C>Чтобы восстановить положительное значение — тебе надо поправить третье поле. В ряде случаев можно автоматически корректировать третье поле, в ряде случаев нельзя.
Так не надо валить в кучу валидность и databinding. В wpf эти задачи разделены, есть Binding для связывания, а есть IDataErrorInfo для доставки пользователю информации о валидноси введенных данных.
Вы нарушаете SRP от этого у вас проблемы. WPF тут не при чем.
C>Ещё есть шутки с граничными условиями. Например, у нас есть два режима вычисления при значении N ползунка N>50 и N<50. Мы подводим к 49 и из-за округления он устанавливается на 51, а обратное вычисление скидывает его на 50, которое округляется до 49, которое снова устанавливается в 51 и т.д.
А причем тут интерфейс? Вы и код не сможете написать что бы он так работал, у вас сразу же бесконечный цикл получится.
Короче не надо сказки выдумывать.
G>>Если вы продолжаете считать что WPF не подходит для ваших задач можете попробоавть другую проблему описать, которую вам не удалось решить. C>Сложно просто модельный пример сделать, где всякие тонкие эффекты видно было бы.
Конечно сложно, потому что таких тонкостей, по которые вы сказки рассказываете просто нету, а если есть, то очень легко обходятся.
C>>>А при восстановлении целостности тоже интересные результаты — несколько контролов одновременно могут решить пересчитаться, что вызывает проблемы с зависимостями. И это даже не у одного меня встречается — G>>Да вот видимо только у вас одно это всречается. Вам Qbit уже написал почему вынос зависимостей во viewmodel помогает. G>>Вкратце объясняю: у вас не будет бешеных зависимостей между контролами. C>А не деться от них никуда. Такие зависимости в формулах.
Ну и пусть будут в формулах, интерфейс тут при чем?
Вы пытаетесь все свалить в одну кучу: интерфейс, байндинг, валидацию и еще что-то, а потом геройски боретесь с получившимися проблемами путем создания фреймворков на сотни килобайт кода.
G>>>>Я уверен что и с количеством можно что-то сделать если применить ViewModel и повторно используемые DataTemplate. C>>>Они заметно разные. G>>Да ну, напишите мне в личку чем отличаются друг от друга все 5000, я даже почитаю. C>Нет, контролы сами не отличаются. Их там что-то всего штук 10 видов. Отличаются вычисления, привязанные к ним.
Тогда вообще проблем не вижу, делаете наследников абстрактного viewmodel в которых реализуете вычисления и проверки.
C>>>Кое-что там общее, но много различий. Это формы налоговой и страховой отчётности, для всех 50 штатов в США и десятка крупных страховых компаний. Хорошо хоть, что мы купили готовые формы в виде XMLей с описанием полей и таблицы расчёта налогов. G>>Ну так вам и флаг в руки, напишите код который парсит xml и создает нужные контролы. C>Так написали. Создать контролы и показать их — это фигня, мелочь. Проблема что с ними дальше делать.
При нормальном подходе больше ничего с контролами делать не надо, все остальные проблемы ложаться на viewmodel. В которой нету трахов с байндингом, валидацией и прочей мутью.
Здравствуйте, MxKazan, Вы писали:
C>>>>Так что с WPF или аналогичными механизмами — нужно делать промежуточный слой визуальных моделей. Мне вот это счастье нафиг не нужно. G>>>Это "счастье" называет MVVM, вы считаете такой подход ненужным? C>>Я не считаю нужным создание лишнего слоя только для того, чтобы ощутить всю крутость байндинга в WPF, если можно обойтись другими способами. MK>А че бы тогда вообще не перестать использовать ООП. Пиши всё на голом C, на фиг тебе лишнии слои? Ну право, несмешно ведь уже. Ясно видно, что ты не пробовал изменить взгляд на вещи и начать разрабатывать интерфейс приложения по другому: когда логика в одном классе, представление в другом (хотя вроде ссылался на что-то подобное). Только, разрабатывая нечто подобное, можно понять все плюсы этого подхода. Да хотя-бы то, что бизнес-логика практически перестает быть связанной с такой вещью как события контролов, что клиентские бизнес-задачи решаются одним классом, который понятия не имеет "как это нарисуется" — только за это уже стоит взятся за MVVM. А ты лишний слой... Это как торт из печенки! Можно сделать слоями и всё будет вкусно, а можно накидать превратить всё это в кашу и потушить — тоже есть можно, но уже не то...
Здравствуйте, Cyberax, Вы писали:
C>Тебе, куй, вообще говорить что-то бесполезно. Кроме себя ты никого больше не слышишь. Примерно как Шеридан.
Да тут их вообще гнездо! В ответе на этот пост
Здравствуйте, gandjustas, Вы писали:
G>Так не надо валить в кучу валидность и databinding. В wpf эти задачи разделены, есть Binding для связывания, а есть IDataErrorInfo для доставки пользователю информации о валидноси введенных данных. G>Вы нарушаете SRP от этого у вас проблемы. WPF тут не при чем.
Я уж десять раз повторяю, что мне для отдельного контрола байндинг особого смысла не имеет. Нужно делать байндинг на уровне всей формы (или группы форм сразу), с учётом связей и зависимостей.
Как доставить ошибки для рисования — это ТАКАЯ мелочь.
C>>Ещё есть шутки с граничными условиями. Например, у нас есть два режима вычисления при значении N ползунка N>50 и N<50. Мы подводим к 49 и из-за округления он устанавливается на 51, а обратное вычисление скидывает его на 50, которое округляется до 49, которое снова устанавливается в 51 и т.д. G>А причем тут интерфейс? Вы и код не сможете написать что бы он так работал, у вас сразу же бесконечный цикл получится.
Смогу. У меня есть детектор таких циклов (зря ты думаешь оно 180Кб занимает и использует rule engine?) — в этом случае прекращается вычисление всей зацикленной группы контролов и они помечаются как ошибочные.
G>>>Да ну, напишите мне в личку чем отличаются друг от друга все 5000, я даже почитаю. C>>Нет, контролы сами не отличаются. Их там что-то всего штук 10 видов. Отличаются вычисления, привязанные к ним. G>Тогда вообще проблем не вижу, делаете наследников абстрактного viewmodel в которых реализуете вычисления и проверки.
Блиииииинннн.
G>>>Ну так вам и флаг в руки, напишите код который парсит xml и создает нужные контролы. C>>Так написали. Создать контролы и показать их — это фигня, мелочь. Проблема что с ними дальше делать. G>При нормальном подходе больше ничего с контролами делать не надо, все остальные проблемы ложаться на viewmodel. В которой нету трахов с байндингом, валидацией и прочей мутью.
Не, ну ладно. Сделали для каждого контрола поле во viewmodel, которое автоматически синхронизируется с контролом. Причём куча полей будет абсолютно искусственными, так как привязать поле к результату вычисления напрямую — сложно.
И чего мы в итоге добились? Чем "myViemodel.name" отличается от 'getControl("controlName").getText()' для дальнейшего использования в вычислениях?
Здравствуйте, Cyberax, Вы писали:
C>И чего мы в итоге добились? Чем "myViemodel.name" отличается от 'getControl("controlName").getText()' для дальнейшего использования в вычислениях?
0_o Так я не понял, у тебя что, имена ещё и литералами задаются? Т. е. компилятор не проверит в compile time корректность имени контрола и его типа? OMFG, facepalm.jpg.
C>Чем "myViemodel.name" отличается от 'getControl("controlName").getText()' для дальнейшего использования в вычислениях?
Тем, что во втором случае ты не можешь просто заменить одну морду на другую (тестовую/эмулирующую или просто альтернативную), придётся копипастить и править логику представления — ведь она у тебя прямо завязана на контролы. Ты даже не можешь без приключений переименовать контрол, потому что это придётся делать не с помощью синтаксического анализатора, а с помощью небезопасного лексического (тупой поиск строки в текстовых литералах). Не говоря уже о том, что ViewModel.UserAge куда выразительнее отражает идею, чем int.parse(getControl("userNameTextBox").getText()).
почти все отметились Q>О, CreatorCray, а ты здесь какими судьбами? Уже решил на C++ задачку с фильтрацией строк файла?
А вот и еще птенец из гнезда подтянулся.
Здравствуйте, Qbit86, Вы писали:
Q>0_o Так я не понял, у тебя что, имена ещё и литералами задаются? Т. е. компилятор не проверит в compile time корректность имени контрола и его типа? OMFG, facepalm.jpg. C>>Чем "myViemodel.name" отличается от 'getControl("controlName").getText()' для дальнейшего использования в вычислениях?
Они задаются аннотациями в скриптах, но это мелочи. Контроля компилятора нет, есть специальная утиллита проверки.
Q>Тем, что во втором случае ты не можешь просто заменить одну морду на другую (тестовую/эмулирующую или просто альтернативную), придётся копипастить и править логику представления — ведь она у тебя прямо завязана на контролы. Ты даже не можешь без приключений переименовать контрол, потому что это придётся делать не с помощью синтаксического анализатора, а с помощью небезопасного лексического (тупой поиск строки в текстовых литералах). Не говоря уже о том, что ViewModel.UserAge куда выразительнее отражает идею, чем int.parse(getControl("userNameTextBox").getText()).
Чем? У меня НЕТ поля ViewModel.UserAge в модели данных. Грубо говоря, у меня есть DataModel.DateOfBirth, которую надо привязать к контролу с возрастом. Как ты это будешь делать?
У меня это ровно одна строчка кода типа: "context.DateOfBirth <[coerceYear[context.Now().subtract(_1.millis)]]> controls.someform.UserAge". Считай, что метод CalculateAge у тебя есть.
