Привязка
Введение в привязку данных
В WPF привязка (binding) является мощным инструментом программирования, без которого не обходится ни одно серьезное приложение.
Привязка подразумевает взаимодействие двух объектов: источника и приемника. Объект-приемник создает привязку к определенному свойству объекта-источника. В случае модификации объекта-источника, объект-приемник также будет модифицирован. Например, простейшая форма с использованием привязки:
Для определения привязки используется выражение типа:
Работа с привязкой в C#
В данном случае получаем привязку для свойства зависимостей TextProperty элемента myTextBlock.
Также можно полностью установить привязку в коде C#:
Если в дальнейшем нам станет не нужна привязка, то мы можем воспользоваться классом BindingOperations и его методами ClearBinding() (удаляет одну привязку) и ClearAllBindings() (удаляет все привязки для данного элемента)
Некоторые свойства класса Binding :
ElementName : имя элемента, к которому создается привязка
IsAsync : если установлено в True, то использует асинхронный режим получения данных из объекта. По умолчанию равно False
Mode : режим привязки
Path : ссылка на свойство объекта, к которому идет привязка
TargetNullValue : устанавливает значение по умолчанию, если привязанное свойство источника привязки имеет значение null
RelativeSource : создает привязку относительно текущего объекта
Source : указывает на объект-источник, если он не является элементом управления.
XPath : используется вместо свойства path для указания пути к xml-данным
Режимы привязки
Свойство Mode объекта Binding, которое представляет режим привязки, может принимать следующие значения:
OneWay : свойство объекта-приемника изменяется после модификации свойства объекта-источника.
OneTime : свойство объекта-приемника устанавливается по свойству объекта-источника только один раз. В дальнейшем изменения в источнике никак не влияют на объект-приемник.
OneWayToSource : объект-приемник, в котором объявлена привязка, меняет объект-источник.
Применение режима привязки:
Обновление привязки. UpdateSourceTrigger
Односторонняя привязка от источника к приемнику практически мгновенно изменяет свойство приемника. Но если мы используем двустороннюю привязку в случае с текстовыми полями (как в примере выше), то при изменении приемника свойство источника не изменяется мгновенно. Так, в примере выше, чтобы текстовое поле-источник изменилось, нам надо перевести фокус с текстового поля-приемника. И в данном случае в дело вступает свойство UpdateSourceTrigger класса Binding, которое задает, как будет присходить обновление. Это свойство в качестве принимает одно из значений перечисления UpdateSourceTrigger :
PropertyChanged : источник привязки обновляется сразу после обновления свойства в приемнике
LostFocus : источник привязки обновляется только после потери фокуса приемником
Explicit : источник не обновляется до тех пор, пока не будет вызван метод BindingExpression.UpdateSource()
Свойство Source
Свойство Source позволяет установить привязку даже к тем объектам, которые не являются элементами управления WPF. Например, определим класс Phone:
Теперь создадим объект этого класса и определим к нему привязку:
Свойство TargetNullValue
На случай, если свойство в источнике привязки вдруг имеет значение null, то есть оно не установлено, мы можем задать некоторое значение по умолчанию. Например:
В данном случае у ресурса nexusPhone не установлено свойство Title, поэтому текстовый блок будет выводить значение по умолчанию, указанное в параметре TargetNullValue.
Свойство RelativeSource
Свойство RelativeSource позволяет установить привязку относительно элемента-источника, который связан какими-нибудь отношениями с элементом-приемником. Например, элемент-источник может быть одним из внешних контейнеров для элемента-приемника. Либо источником и приемником может быть один и тот же элемент.
Self : привязка осуществляется к свойству этого же элемента. То есть элемент-источник привязки в то же время является и приемником привязки.
FindAncestor : привязка осуществляется к свойству элемента-контейнера.
Например, совместим источник и приемник привязке в самом элементе:
Здесь текст и фоновый цвет текстового поля связаны двусторонней привязкой. В итоге мы можем увидеть в поле числовое значение цвета, поменять его, и вместе с ним изменится и фон поля.
Привязка к свойствам контейнера:
При использовании режима FindAncestor, то есть привязке к контейнеру, необходимо еще указывать параметр AncestorType и передавать ему тип контейнера в виде выражения AncestorType=
Свойство DataContext
Таким образом мы задаем свойству DataContext некоторый динамический или статический ресурс. Затем осуществляем привязку к этому ресурсу.
Как работает двухсторонний биндинг в современных JavaScript-фреймворках
Содержание статьи
Что такое двухсторонний биндинг данных?
JavaScript позволяет построить интерактивное взаимодействие с пользователем за счет реакции на его действия визуальными событиями. Человек вводит данные в форму, нажимает кнопку «Отправить», на странице появляется индикатор загрузки, а после (предположим, что была допущена ошибка) неправильно заполненные поля подсвечиваются красным. В этот момент под капотом приложения происходит примерно следующее:
Классический JS + jQuery код работал бы примерно следующим образом:
WARNING
В пункте 7 есть огромный риск нарушить инкапсуляцию — мы начинаем модифицировать представление. Где должна храниться эта логика? Как избежать ее дублирования с тем, что сгенерировало страницу изначально? Обычно именно на этом месте большинство фронтенд-кода превращается в лапшу.
Двухсторонний биндинг данных избавляет нас от шагов 2, 5 и 7, попутно однозначно решая проблему инкапсуляции логики представления (или, как сейчас модно считать, избавляет представление от логики вовсе).
Чтобы отобразить такой объект в нужную нам форму, понадобится примерно вот такой шаблон (нотация Underscore Template):
Теперь если каким-то чудом при любом изменении нашего input его значение будет автоматически попадать в entity.name и, наоборот, при изменении чего угодно в entity этот шаблон будет обновляться необходимым образом — это и будет двухсторонний биндинг данных. Наше представление полностью описывает логику отображения исходя из возможного состояния, а само приложение, не думая о DOM, это состояние меняет.
Проблемы реализации
К сожалению, пример выше — просто пример. В реальной жизни ему не хватает очень большого количества метаинформации, без которой подобный биндинг попросту не заработает. Чтобы все заработало в универсальном случае, нам надо разобраться хотя бы со следующим:
Для решения всех этих проблем каждый фреймворк предлагает свои костыли — уникальные решения, которые вносят ложку дегтя в такую красивую теорию. Самое время вставить наш микроскоп поглубже в каждый из них и понять, что же двухсторонний биндинг данных представляет собой на самом деле и откуда берутся некоторые, порой такие странные ограничения привычных нам инструментов.
Смотреть мы будем на три примера: * Angular — как канонический пример «нового лучшего HTML»; * Ember — как пример привязки более классической парадигмы JS к новому инструменту и, конечно, * Joosy — как живая демонстрация моего субъективного видения удобного двухстороннего биндинга.
Отслеживание изменений объекта
К сожалению, никаких универсальных способов отследить любые изменения объекта в JS попросту нет. Все существующие решения накладывают ограничения на то, как с объектом производится работа. А решений существует целых два: работа через сеттеры/геттеры и внешний мониторинг.
Сеттеры/геттеры (Ember, Joosy)
Ember
Геттеры и сеттеры являются центральным стержнем системы свойств Ember. Они позволяют не только оповещать об изменении объекта, но и подписываться на изменение конкретных полей. В базе все выглядит именно так, как было описано:
HISTORY
Если понаблюдать, как развиваются фреймворки, то мы увидим один забавный повторяющийся виток. Комплексные фреймворки а-ля Rails потихоньку разбиваются на множество независимых компонентов, которые можно использовать отдельно. Объекты с отслеживанием изменений — прекрасный кандидат на вынос из Ember/Joosy в независимую библиотеку с выделенным API.
Joosy
Геттеры и сеттеры для объектов в Joosy работают совершенно идентичным образом за тем лишь исключением, что в Joosy отсутствует подписка на изменение конкретного поля. Joosy не умеет следить за полями, он следит только за изменением сущности в целом (правда, событие об изменении все-таки содержит информацию о том, что же изменилось). За счет этого массивы организованы чуть проще:
Кроме этого, для хешей Joosy (мимикрируя под Ruby) дает возможность прямо объявить необходимые свойства.
Внешний мониторинг (Angular)
Архитектура Angular вводит «цикл отрисовки», одним из шагов которого является проверка по указанному списку отслеживания — а не изменилось ли чего. К каждому элементу списка отслеживания можно прицепить одну или несколько функций, которые вызовутся, как только значение изменится. Такое решение прозрачно работает с любыми способами установки атрибута (нет нужды в set или поддерживании списка полей), но и это, увы, не серебряная пуля.
А вообще, просто попробуй поискать angular watch на StackOverflow.com, и все сразу станет на свои места.
Секционирование страницы
Декларативные шаблоны (Angular, Ember)
Одна из причин, по которым Angular нужен «новый HTML», а Ember — Handlebars, именно в этом. Декларативное описание, которое они разбирают своим собственным внутренним парсером, дает им информацию о контекстах биндингов.
По этой же логике работают условия ( ng_if и <% raw %><
Флагом такого подхода является девиз: «Шаблоны не должны содержать логику!» Хотя я, откровенно говоря, считаю, что это как раз следствие, а не правило. В подобную декларативную нотацию уж очень накладно было бы встраивать полноценный логический язык. А так и волки сыты, и овцы целы. И язык не нужен, и к высшей цели пришли — вроде как логика в шаблонах — это плохо?
В реальности все не так просто. Логика не может испариться из твоего приложения, где-то она все равно должна быть. И если ее нет напрямую в шаблонах, то она должна попадать в шаблон в виде состояния. Это значит, что на каждый чих нам понадобится виртуальное состояние. Обработка индикаторов загрузки, условий доступности, факта «выбранности», абсолютно каждого мелкого переключателя. К сожалению, понимание, насколько серьезна эта плата, приходит уже в конце, когда приложение начинает обрастать мелкими удобствами.
Ручное секционирование (Joosy)
Мне всегда очень хотелось остаться с любимым HAML (в вариации с CoffeeScript), но таким образом, чтобы сохранить основные возможности двухстороннего биндига. Для достижения этой цели в Joosy используется ручное секционирование. На место декларативных объявлений пришли классические хелперы, набор которых позволяет определить регион и объявить его локальные объекты (при их изменении весь регион будет обновлен).
Например, чтобы достичь поведения, похожего на ng_repeat Angular или each Ember, можно написать что-то такое:
Теперь, когда поменяется @projects или любой проект из их числа, все автоматически окажется в DOM. Обрати внимание, что смотрители регионов специально сделаны таким образом, чтобы мониторить коллекцию с полной вложенностью. Поэтому сегмент на весь блок всего один.
Кроме инлайн-блоков, Joosy умеет рендерить в виде региона классический partial (прямо как в Rails). Это даже куда более частый случай.
Такой подход приводит к тому, что регионов в Joosy обычно гораздо меньше, чем в Angular или Ember. Практика показывает, что производительности это не мешает. Зато дает возможность работать с абсолютно любым языком шаблонов, с абсолютно любой логической нотацией и вручную управлять динамической привязкой (включая возможность завязать перерисовку региона на объект, который в нем не используется), что иногда бывает ох как полезно.
Минус — обратная сторона плюса, вручную всем управлять не только можно, но и необходимо. Нет объявленных регионов — нет двухстороннего биндинга. Другая теоретическая проблема — работа с огромными регионами (1000 строк в таблице). Так как в Joosy каждый массив создает всего один регион, обновление любого объекта этого массива приведет к полной перерисовке всего региона. В этом edge-случае по умолчанию хорошо себя ведет только Ember. Joosy и Angular потребуют ручной оптимизации биндинга.
Частичное обновление DOM
Теперь у нас есть регионы, которые ждут изменения своего набора объектов и автоматически перерисовываются. Жизнь вроде бы налаживается. Но есть еще одна проблема, которую надо решить:
Metamorph (Ember, Joosy)
Ember и Joosy используют одно решение. Изначально (Joosy писался параллельно с Ember) мы просто написали одно и то же. В итоге оказалось, что решение Ember очень удачно обернуто во внешнюю библиотеку, — и Metamorph, надо сказать, прекрасно справляется с поставленной задачей.
В современных браузерах Metamorph просто использует W3C Ranges, а вот в старых все куда интереснее. Регион оборачивается в два тега
Check Also
WinAFL на практике. Учимся работать фаззером и искать дыры в софте
WinAFL — это форк знаменитого фаззера AFL, предназначенный для фаззинга программ с закрыты…
WPF Binding: Что означает ?
Этой первой статьей я бы хотел начать цикл переводов постов с замечательного блога, в котором Beatriz Costa детально объясняет определенные аспекты Binding’а в WPF. В первом посте затрагивается тема использования Binding’а без указания каких-либо дополнительных свойств.
В основном, Binding’и, которые вы видите в различных примерах, имеют определенные значения свойств Source и Path. Свойство Source определяет объект, на который направляется Binding, а свойство Path определяет свойство у объекта, значение которого вам нужно. Я видела некоторых людей, которых cбивала с толку их первая встреча с пустым Binding’ом — «
Первый подход, это когда источником выступает строка и вы просто хотите указать на всю строку целиком (а, к примеру, не на ее свойство Length).
Заметьте, что у Binding’а внутри DataTemplat’а не определено свойство Source. Это из-за того, что DataContext автоматически устанавливается как Source.
Здесь вы можете найти проект для Visual Studio с кодом, который был использован в статье.
От переводчика:
Автор оригинальной статьи — женщина, поэтому текст перевода написан от женского лица.
Так же хотелось бы узнать, насколько интересна тема Binding’а хабролюдям, и стоит ли продолжать эту серию переводов.
Идея перевода навеяна постом WPF Series: Intro aka Введение.
Биндинги (bindings)
Биндинг представляет из себя функцию, которая принимает единственный параметр node – владелец шаблона, для которого вычисляется значение. Результат выполнения такой функции передается шаблону. Функция не должна иметь побочного эффекта, то есть не должна что-то менять в объектах.
Функция биндинга вычисляется сразу после создания экземпляра шаблона, но только в том случае, если шаблон использует биндинг. По этой причине не важно количество биндингов: вычисляться будут только используемые.
Так же в качестве описания биндига принимаются некоторые специальные значения:
объект, поддерживающий механизм binding bridge – значение отдается в шаблон как есть;
строка – используется, если возможно, преобразование сокращения, иначе значение оборачивается в basis.getter;
Сокращения
В модуле basis.ui определены два типа сокращения:
data – предназначен для упрощения прокидывания полей из свойства data в шаблон;
satellite – предназначен для упрощения прокидывания корневого элемента сателлита в шаблон;
Биндинги по умолчанию
Для basis.ui.Node и basis.ui.PartitionNode определен ряд биндигов, которые доступны по умолчанию (в скобках указаны события):
state (stateChanged) – возвращает строковое значение свойства state ;
childNodesState (childNodesStateChanged) – возвращает строковое значение свойства childNodesState ;
childCount (childNodesModified) – возвращает число дочерних узлов;
hasChildren (childNodesModified) – возвращает true если есть дочерние узлы и false в ином случае;
empty (childNodesModified) – возвращает true если нет дочерних узлов и false в ином случае;
Для basis.ui.Node так же определены дополнительные биндинги:
Общие сведения о привязках Windows Communication Foundation
привязки — это объекты, которые используются для указания сведений о соединении, необходимых для подключения к конечной точке службы Windows Communication Foundation (WCF). Для каждой конечной точки в службе WCF необходимо правильно указать привязку. В этом разделе описываются типы сведений о соединении, определяемые привязками, элементы привязки, привязки, которые включаются в WCF, а также способ указания привязки для конечной точки.
Что определяет привязка
Информация в привязке может быть очень простой или очень сложной. Самые простые привязки указывают только транспортный протокол (такой как HTTP), который должен использоваться для подключения к конечной точке. Более того, информация, которую содержит привязка, включает сведения о том, как подключиться к конечной точке, попадает в одну из следующих категорий.
Протоколы
Определяют используемый механизм безопасности: возможность надежного обмена сообщениями или параметры потока контекста транзакций.
Кодирование
Определяет используемую в сообщениях кодировку (например, текст или двоичное кодирование).
Транспорт
Определяет основной используемый транспортный протокол (например, TCP или HTTP).
Элементы привязки
Привязки, предоставляемые системой
Информация в привязке может быть сложной, а некоторые параметры могут быть несовместимыми с другими. По этой причине в WCF включен набор привязок, предоставляемых системой. Эти привязки удовлетворяют большинство требований приложения. В следующих классах представлены некоторые примеры привязок, предоставляемых системой.
BasicHttpBinding: привязка протокола HTTP, которая подходит для подключения к веб-службам, соответствующим спецификации WS-I Basic Profile (например, службы на основе веб-службы ASP.NET).
WSHttpBinding: привязка с возможностью взаимодействия, которая подходит для подключения к конечным точкам, соответствующим протоколам WS-*.
NetTcpBinding: Эта привязка обеспечивает более высокую производительность по сравнению с HTTP-привязками и идеально подходит для использования в локальной сети.
Полный список с описаниями всех привязок, предоставляемых WCF, см. в разделе привязки, предоставляемые системой.
Использование собственных привязок
Если ни одна из предоставляемых системой привязок не имеет требуемого приложением службы сочетания возможностей, можно создать собственную привязку. Это можно сделать двумя способами. Можно создать новую привязку из уже имеющихся элементов привязки с помощью объекта CustomBinding или создать полностью пользовательскую привязку, наследуемую от привязки Binding. Дополнительные сведения о создании собственной привязки с помощью этих двух подходов см. в разделе пользовательские привязки и создание привязок User-Defined.
Использование привязок
Использование привязок включает два основных этапа.
Выбор или определение привязки. Самый простой способ — выбрать одну из предоставляемых системой привязок, включенных в WCF, и использовать ее с параметрами по умолчанию. Также можно выбрать предоставляемую системой привязку и сбросить значения ее свойств таким образом, чтобы они соответствовали нужным требованиям. Кроме того, можно создать пользовательскую или определяемую пользователем привязку с расширенными возможностями управления и настройки.
Создайте конечную точку, которая использует выбранную или определенную привязку.