Здравствуйте, gandjustas, Вы писали:
C>>Тебе никогда не встречался случай, что байндинг имеет недостаточную мощность? G>В WPF — нет. зато я знаю множество людей, которые не знают\не понимают возможностей байндинга в WPF.
Поздравляю. А вот мне встречался — сложные динамические формы со сложным байндингом (с циклическими связями, меняющимися, возможно зацикливающимися или частично некорректными). Тот dependency solver, который есть в WPF — не справляется и близко.
C>>У меня такие случаи попадаются постоянно. Я пока не знаю системы байндинга, которая была бы достаточно мощной для моих целей. G>Может стоит повнимательнее изучить существующие?
Изучил.
C>>Триггеры предназначены, прежде всего, для простых действий, типа установки фокуса в нужное место при нажатии или запуска анимации. G>Это кто такую глупость сказал? Триггер может запустить Storyboard, а он в свою очередь может сделать парктически все.
И чем это отличается от простой передачи события? Ответ: ничем.
Ещё раз повторяю: всякая красивая анимация мне нафиг не нужна. Я прекрасно знаю, как делать всякие мигающие кнопки в WPF. Неинтересно.
C>>У меня всё сложнее. G>Также сложно как с embedded LDAP? G>Мне кажется что вы очередной раз выдумываете сложности.
Нет. Такая реальность — нужно делать интерфейсы к сложным legacy-системам.
G>>>"Использовал" надо заменить на "видел". C>>Нет, именно использовал. В первый раз ещё в 2007-м, если не ошибаюсь (до появления XAML-редактора). G>А последний?
Где-то перед Новым Годом — коннектор делал для одних клиентов.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Тебе никогда не встречался случай, что байндинг имеет недостаточную мощность? G>>В WPF — нет. зато я знаю множество людей, которые не знают\не понимают возможностей байндинга в WPF. C>Поздравляю. А вот мне встречался — сложные динамические формы со сложным байндингом (с циклическими связями, меняющимися, возможно зацикливающимися или частично некорректными). Тот dependency solver, который есть в WPF — не справляется и близко.
А человек, который должен с этими формами работать, он справлялся?
Кстати попрдробнее про циклические связи можно? Как оно вообще работает?
ИМХО очередная надуманная сложность как embeddep LDAP.
C>>>У меня такие случаи попадаются постоянно. Я пока не знаю системы байндинга, которая была бы достаточно мощной для моих целей. G>>Может стоит повнимательнее изучить существующие? C>Изучил.
Судя по постам — не совсем.
C>>>Триггеры предназначены, прежде всего, для простых действий, типа установки фокуса в нужное место при нажатии или запуска анимации. G>>Это кто такую глупость сказал? Триггер может запустить Storyboard, а он в свою очередь может сделать парктически все. C>И чем это отличается от простой передачи события? Ответ: ничем.
Передачи события кому?
C>>>У меня всё сложнее. G>>Также сложно как с embedded LDAP? G>>Мне кажется что вы очередной раз выдумываете сложности. C>Нет. Такая реальность — нужно делать интерфейсы к сложным legacy-системам.
И почему эти интерфейсы должны быть сложными?
Здравствуйте, gandjustas, Вы писали:
C>>Поздравляю. А вот мне встречался — сложные динамические формы со сложным байндингом (с циклическими связями, меняющимися, возможно зацикливающимися или частично некорректными). Тот dependency solver, который есть в WPF — не справляется и близко. G>А человек, который должен с этими формами работать, он справлялся?
С трудом. Для того софт и пишем.
G>Кстати попрдробнее про циклические связи можно? Как оно вообще работает?
Простой пример — два поля. В одно поле вводят число, другое поле показывает процент от этого числа, оба поля редактируемые. Соответственно, если пользователь меняет одно поле, то должно поменяться другое.
Или другой пример — колонка чисел и сумма. Можно редактировать отдельные поля и поле суммы. При редактировании поля суммы по хитрым правилам должны редактироваться слагаемые. Причём слагаемые могут меняться динамически (например, изменили сумму до $100 — и одно поле заменилось другим, а все значения пересчитались, а если изменили до $110 — это поле снова исчезнет).
G>ИМХО очередная надуманная сложность как embeddep LDAP.
Ничуть.
G>>>Это кто такую глупость сказал? Триггер может запустить Storyboard, а он в свою очередь может сделать парктически все. C>>И чем это отличается от простой передачи события? Ответ: ничем. G>Передачи события кому?
Обработчику событий.
G>>>Также сложно как с embedded LDAP? G>>>Мне кажется что вы очередной раз выдумываете сложности. C>>Нет. Такая реальность — нужно делать интерфейсы к сложным legacy-системам. G>И почему эти интерфейсы должны быть сложными?
Так уж получается.
Здравствуйте, Cyberax, Вы писали:
G>>Кстати попрдробнее про циклические связи можно? Как оно вообще работает? C>Простой пример — два поля. В одно поле вводят число, другое поле показывает процент от этого числа, оба поля редактируемые. Соответственно, если пользователь меняет одно поле, то должно поменяться другое.
Two-way binding + converter вы считаете такой сложностью? WPF с этим спокойно справляется.
C>Или другой пример — колонка чисел и сумма. Можно редактировать отдельные поля и поле суммы. При редактировании поля суммы по хитрым правилам должны редактироваться слагаемые. Причём слагаемые могут меняться динамически (например, изменили сумму до $100 — и одно поле заменилось другим, а все значения пересчитались, а если изменили до $110 — это поле снова исчезнет).
Это уже MVVM использовать надо, и байндиться на свойства ViewModel.
Та и другая задача вполне спокойно решается в WPF.
Здравствуйте, Cyberax, Вы писали:
C>>>Тебе никогда не встречался случай, что байндинг имеет недостаточную мощность? G>>В WPF — нет. зато я знаю множество людей, которые не знают\не понимают возможностей байндинга в WPF. C>Поздравляю. А вот мне встречался — сложные динамические формы со сложным байндингом (с циклическими связями, меняющимися, возможно зацикливающимися или частично некорректными). Тот dependency solver, который есть в WPF — не справляется и близко.
Пример "циклической связи" в студию.
C>>>У меня такие случаи попадаются постоянно. Я пока не знаю системы байндинга, которая была бы достаточно мощной для моих целей. G>>Может стоит повнимательнее изучить существующие? C>Изучил.
Не заметно.
Здравствуйте, gandjustas, Вы писали:
C>>Простой пример — два поля. В одно поле вводят число, другое поле показывает процент от этого числа, оба поля редактируемые. Соответственно, если пользователь меняет одно поле, то должно поменяться другое. G>Two-way binding + converter вы считаете такой сложностью? WPF с этим спокойно справляется.
А теперь идём дальше. Например, нужно учитывать, что если мы редактируем деньги, то нам нужно иногда округлять их до десятков центов.
Т.е. имеем сумму $5.00 в поле денег, и 100% в поле ввода процентов. Меняем 100% на 73% — должно получиться $3.60 ($3.65 округлённый в меньшую сторону), так что процент должен скомпенсироваться до 72%. Или наоборот, нужно иметь целые проценты, но при редактировании суммы дробные проценты нужно округлять.
И иногда это нужно делать через цепочку промежуточных преобразований.
В простых случаях можно пробовать вызывать из ConvertBack из Convert (и наоборот), но если нужно что-то более сложное — то упс. Ну и сам интерфейс конвертера не особо приятный. Мало информации о контексте преобразования и его истории, нет чётких механизмов ветирования и отката изменений до вычисленного корректного состояния и т.п.
Плюс, многие формулы валидации работают в одном направлении (и решать их в обратном направлении — совсем недосуг). Мне для binding'а пришлось вообще прикручивать логический движок, а ты говоришь "простой two-way"...
Мне пока единственное что не нравится — у меня биективные преобразования ничем не проверяются (т.е. из-за глюков они бывают и не биективными), поэтому и хочется механизм линз прикрутить и переделать на них большую часть вычислений. Единственное, что пока не разобрался что делать с решателем ограничений.
C>>Или другой пример — колонка чисел и сумма. Можно редактировать отдельные поля и поле суммы. При редактировании поля суммы по хитрым правилам должны редактироваться слагаемые. Причём слагаемые могут меняться динамически (например, изменили сумму до $100 — и одно поле заменилось другим, а все значения пересчитались, а если изменили до $110 — это поле снова исчезнет). G>Это уже MVVM использовать надо, и байндиться на свойства ViewModel.
И она будет повторять визуальную модель.
Здравствуйте, Cyberax, Вы писали:
C>>>Поздравляю. А вот мне встречался — сложные динамические формы со сложным байндингом (с циклическими связями, меняющимися, возможно зацикливающимися или частично некорректными). Тот dependency solver, который есть в WPF — не справляется и близко. G>>А человек, который должен с этими формами работать, он справлялся? C>С трудом. Для того софт и пишем.
G>>Кстати попрдробнее про циклические связи можно? Как оно вообще работает? C>Простой пример — два поля. В одно поле вводят число, другое поле показывает процент от этого числа, оба поля редактируемые. Соответственно, если пользователь меняет одно поле, то должно поменяться другое.
И где здесь циклическая связь?
Обычный двунаправленный байндинг на два поля. При обновлении одного из них контроллер (ViewModel) обновляет второе.
C>Или другой пример — колонка чисел и сумма. Можно редактировать отдельные поля и поле суммы. При редактировании поля суммы по хитрым правилам должны редактироваться слагаемые. Причём слагаемые могут меняться динамически (например, изменили сумму до $100 — и одно поле заменилось другим, а все значения пересчитались, а если изменили до $110 — это поле снова исчезнет).
Ты, похоже, вообще не понимаешь что такое WPF, что такое MVVM... ппц Лучше не пиши больше — не позорься так.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Простой пример — два поля. В одно поле вводят число, другое поле показывает процент от этого числа, оба поля редактируемые. Соответственно, если пользователь меняет одно поле, то должно поменяться другое. G>>Two-way binding + converter вы считаете такой сложностью? WPF с этим спокойно справляется. C>А теперь идём дальше. Например, нужно учитывать, что если мы редактируем деньги, то нам нужно иногда округлять их до десятков центов.
C>Т.е. имеем сумму $5.00 в поле денег, и 100% в поле ввода процентов. Меняем 100% на 73% — должно получиться $3.60 ($3.65 округлённый в меньшую сторону), так что процент должен скомпенсироваться до 72%. Или наоборот, нужно иметь целые проценты, но при редактировании суммы дробные проценты нужно округлять.
C>И иногда это нужно делать через цепочку промежуточных преобразований.
Если честно, совсем не понимаю вашей проблемы. Как уже неоднократно упоминали, MVVM в руки, вся необходимая логика сосредоточена в классах View Model, проценты, налоги, округления, что хотите. При этом все вопросы отображения берёт на себя декларативный xaml. Какие возникают сложности именно с визуализацией ваших данных?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Простой пример — два поля. В одно поле вводят число, другое поле показывает процент от этого числа, оба поля редактируемые. Соответственно, если пользователь меняет одно поле, то должно поменяться другое. G>>Two-way binding + converter вы считаете такой сложностью? WPF с этим спокойно справляется. C>А теперь идём дальше. Например, нужно учитывать, что если мы редактируем деньги, то нам нужно иногда округлять их до десятков центов.
C>Т.е. имеем сумму $5.00 в поле денег, и 100% в поле ввода процентов. Меняем 100% на 73% — должно получиться $3.60 ($3.65 округлённый в меньшую сторону), так что процент должен скомпенсироваться до 72%. Или наоборот, нужно иметь целые проценты, но при редактировании суммы дробные проценты нужно округлять.
C>И иногда это нужно делать через цепочку промежуточных преобразований.
В таком случае все нетривиальные операции надо проделывать через ViewModel.
C>В простых случаях можно пробовать вызывать из ConvertBack из Convert (и наоборот), но если нужно что-то более сложное — то упс. Ну и сам интерфейс конвертера не особо приятный. Мало информации о контексте преобразования и его истории, нет чётких механизмов ветирования и отката изменений до вычисленного корректного состояния и т.п.
Никогда бы не подумал что простому байндингу нужно "чёткий механизм ветирования и отката изменений до вычисленного корректного состояния и т.п".
делайте это во ViewModel.
C>Плюс, многие формулы валидации работают в одном направлении (и решать их в обратном направлении — совсем недосуг). Мне для binding'а пришлось вообще прикручивать логический движок, а ты говоришь "простой two-way"...
C>Мне пока единственное что не нравится — у меня биективные преобразования ничем не проверяются (т.е. из-за глюков они бывают и не биективными), поэтому и хочется механизм линз прикрутить и переделать на них большую часть вычислений. Единственное, что пока не разобрался что делать с решателем ограничений.
Вы уже раза три подтвердили что неумете использовать WPF. Хватит уже народ смешить.
Как я и говорил что не бывает случаев недостаточной мощности байндинга, бавают случаи неумения его использовать.
C>>>Или другой пример — колонка чисел и сумма. Можно редактировать отдельные поля и поле суммы. При редактировании поля суммы по хитрым правилам должны редактироваться слагаемые. Причём слагаемые могут меняться динамически (например, изменили сумму до $100 — и одно поле заменилось другим, а все значения пересчитались, а если изменили до $110 — это поле снова исчезнет). G>>Это уже MVVM использовать надо, и байндиться на свойства ViewModel. C>И она будет повторять визуальную модель.
А что такое визуальная модель?
Может посмотрите видео по ссылке которую Qbit давал?
Только не надо рассказывать то вы знаете что такое MVVM — это не так.
Здравствуйте, User239, Вы писали:
C>>И иногда это нужно делать через цепочку промежуточных преобразований. U>Если честно, совсем не понимаю вашей проблемы. Как уже неоднократно упоминали, MVVM в руки, вся необходимая логика сосредоточена в классах View Model, проценты, налоги, округления, что хотите. При этом все вопросы отображения берёт на себя декларативный xaml. Какие возникают сложности именно с визуализацией ваших данных?
Проблема в том, что тогда байндинг выражаются в тупой привязке к свойствам. И тогда нет особой разницы — что ставить контролу имя и писать его в атрибуте свойства, что писать в байндинге имя свойства. За исключением того, что прямой доступ к свойствам всё же более гибкий.
Здравствуйте, gandjustas, Вы писали:
G>Никогда бы не подумал что простому байндингу нужно "чёткий механизм ветирования и отката изменений до вычисленного корректного состояния и т.п". G>делайте это во ViewModel.
Внимание, вопрос: а нафиг мне нужен тогда байндинг, если он вырождается в 1-1 привязку к свойствам специальных синтетических объектов?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Никогда бы не подумал что простому байндингу нужно "чёткий механизм ветирования и отката изменений до вычисленного корректного состояния и т.п". G>>делайте это во ViewModel. C>Внимание, вопрос: а нафиг мне нужен тогда байндинг, если он вырождается в 1-1 привязку к свойствам специальных синтетических объектов?
А как другим способом обеспечить двустороннюю передачу данным между свойством "специального синтетического объекта" (который все нормальные люди называют ViewModel), без написани тонны инфраструктурного кода.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, User239, Вы писали:
C>>>И иногда это нужно делать через цепочку промежуточных преобразований. U>>Если честно, совсем не понимаю вашей проблемы. Как уже неоднократно упоминали, MVVM в руки, вся необходимая логика сосредоточена в классах View Model, проценты, налоги, округления, что хотите. При этом все вопросы отображения берёт на себя декларативный xaml. Какие возникают сложности именно с визуализацией ваших данных? C>Проблема в том, что тогда байндинг выражаются в тупой привязке к свойствам.
Может перевести слово binding? По русски оно и будет "привязка".
В впф байндинг нужен именно для "тупой привязки к свойствам".
C>И тогда нет особой разницы — что ставить контролу имя и писать его в атрибуте свойства, что писать в байндинге имя свойства. За исключением того, что прямой доступ к свойствам всё же более гибкий.
Вот приведите код, который показывает что нет особой разницы. Вот как раз с вашими процентами.
Здравствуйте, gandjustas, Вы писали:
C>>Проблема в том, что тогда байндинг выражаются в тупой привязке к свойствам. G>Может перевести слово binding? По русски оно и будет "привязка". G>В впф байндинг нужен именно для "тупой привязки к свойствам".
Мне нужен _не_ тупой байндинг. У меня есть модель данных, которая для вычислений преобразовывается специальным образом (как я уже говорил). Модель данных достаточно далека от того, что видит пользователь.
Так что с WPF или аналогичными механизмами — нужно делать промежуточный слой визуальных моделей. Мне вот это счастье нафиг не нужно.
C>>И тогда нет особой разницы — что ставить контролу имя и писать его в атрибуте свойства, что писать в байндинге имя свойства. За исключением того, что прямой доступ к свойствам всё же более гибкий. G>Вот приведите код, который показывает что нет особой разницы. Вот как раз с вашими процентами.
Великоват он... Это у меня уже почти целый фреймворк. Я могу привести пример как оно выглядит в прикладном коде.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Проблема в том, что тогда байндинг выражаются в тупой привязке к свойствам. G>>Может перевести слово binding? По русски оно и будет "привязка". G>>В впф байндинг нужен именно для "тупой привязки к свойствам". C>Мне нужен _не_ тупой байндинг. У меня есть модель данных, которая для вычислений преобразовывается специальным образом (как я уже говорил). Модель данных достаточно далека от того, что видит пользователь.
Это всегда так.
C>Так что с WPF или аналогичными механизмами — нужно делать промежуточный слой визуальных моделей. Мне вот это счастье нафиг не нужно.
Это "счастье" называет MVVM, вы считаете такой подход ненужным?
А MVC и MVP ?
Не надо обвинять WPF в свойе некомпетентности.
C>>>И тогда нет особой разницы — что ставить контролу имя и писать его в атрибуте свойства, что писать в байндинге имя свойства. За исключением того, что прямой доступ к свойствам всё же более гибкий. G>>Вот приведите код, который показывает что нет особой разницы. Вот как раз с вашими процентами. C>Великоват он... Это у меня уже почти целый фреймворк. Я могу привести пример как оно выглядит в прикладном коде.
Давайте весь код, уж очень интересно во сколько раз удастся его сократить.
Здравствуйте, gandjustas, Вы писали:
C>>Так что с WPF или аналогичными механизмами — нужно делать промежуточный слой визуальных моделей. Мне вот это счастье нафиг не нужно. G>Это "счастье" называет MVVM, вы считаете такой подход ненужным?
Я не считаю нужным создание лишнего слоя только для того, чтобы ощутить всю крутость байндинга в WPF, если можно обойтись другими способами.
G>>>Вот приведите код, который показывает что нет особой разницы. Вот как раз с вашими процентами. C>>Великоват он... Это у меня уже почти целый фреймворк. Я могу привести пример как оно выглядит в прикладном коде. G> G>Давайте весь код, уж очень интересно во сколько раз удастся его сократить.
Весь код я всё равно не дам. Его там сейчас 180 килобайт, не считая библиотек. Пример вечером могу прислать.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Никогда бы не подумал что простому байндингу нужно "чёткий механизм ветирования и отката изменений до вычисленного корректного состояния и т.п". G>>делайте это во ViewModel. C>Внимание, вопрос: а нафиг мне нужен тогда байндинг, если он вырождается в 1-1 привязку к свойствам специальных синтетических объектов?
Ну так байндинг для того и нужен, чтобы отделить вашу логику от представления.
С>Так что с WPF или аналогичными механизмами — нужно делать промежуточный слой визуальных моделей. Мне вот это счастье нафиг не нужно.
Конечно код для "чёткого механизма ветирования и отката изменений до вычисленного корректного состояния" за вас не напишет ни один фреймворк на свете. Вопрос лишь в том, где писать этот код. Если это не "промежуточный слой визуальных моделей", тогда что? Обработчики кнопок (образно)? В этом случае код явно будет больше, чем при байндинге (чего стоят одни getText, setText). Не говоря уж о том, насколько увеличится подверженность различным ошибкам.
Здравствуйте, Cyberax, Вы писали:
C>>>Проблема в том, что тогда байндинг выражаются в тупой привязке к свойствам. G>>Может перевести слово binding? По русски оно и будет "привязка". G>>В впф байндинг нужен именно для "тупой привязки к свойствам". C>Мне нужен _не_ тупой байндинг. У меня есть модель данных, которая для вычислений преобразовывается специальным образом (как я уже говорил). Модель данных достаточно далека от того, что видит пользователь.
C>Так что с WPF или аналогичными механизмами — нужно делать промежуточный слой визуальных моделей. Мне вот это счастье нафиг не нужно.
Я ржал... Ты либо туп либо притворяешься. Тебя уже десять раз ткнули носом, разжевали и положили в клюв, дали мультик посмотреть, а ты все еще не допер как работает MVVM и зачем вообще придумали MVC? Ндааааааааа.....
C>>>И тогда нет особой разницы — что ставить контролу имя и писать его в атрибуте свойства, что писать в байндинге имя свойства. За исключением того, что прямой доступ к свойствам всё же более гибкий. G>>Вот приведите код, который показывает что нет особой разницы. Вот как раз с вашими процентами. C>Великоват он... Это у меня уже почти целый фреймворк. Я могу привести пример как оно выглядит в прикладном коде.
Здравствуйте, Cyberax, Вы писали:
G>>Давайте весь код, уж очень интересно во сколько раз удастся его сократить.
C>PS: вообще поражают меня сторонники ${ПОСЛЕДНЯЯ_ТЕХНОЛОГИЯ}, думающие, что она решает все проблемы. Маловато нестандартных задач, видимо, решают...
Ну давай просвяти нас дурней — расскажи какие такие задачи построения пользовательского интерфейса WPF не решает. Внимательно слушаем тебя, умник.
