Этой первой статьей я бы хотел начать цикл переводов постов с замечательного блога, в котором Beatriz Costa детально объясняет определенные аспекты Binding'а в WPF. В первом посте затрагивается тема использования Binding'а без указания каких-либо дополнительных свойств.

Здравствуйте! Не так давно я написал свой первый перевод поста про WPF Binding из блога Beatriz Cost'ы. Он был принят достаточно хорошо, так что я принял решение регулярно, примерно раз в неделю (иногда, возможно, и чаще), переводить по одному посту из этого блога. В этот раз я решил перевести небольшую (на большие пока нет времени) статью, в которой рассказывается о том, в каких ситуациях лучше использовать DataContext, а в каких свойство Source.

В WPF существует очень четкое разделение между поведением Control'а и тем, как он выглядит. К примеру, поведение объекта класса Button состоит в том, чтобы реагировать на различные события по клику, но его вид может быть любым — вы можете сделать кнопку в виде стрелки, рыбы, или чего-либо еще, что подходит для вашего приложения. Переопределение отображения Control'а очень просто сделать при использовании VS со стилями и шаблонами, и даже еще проще, если у вас есть Microsoft Expression Blend. В этом примере я покажу вам, как переопределить отображение ListBox'а, который используется для отображения списка планет.

В простейшем master-detail сценарии, нажатие на определенный элемент в ItemsControl'е вызывает отображение детальной информации об этом элементе на другом control'е. К примеру, программа может отображать список имен покупателей, и клик по определенному покупателю приведет к тому, что в TextBlock'ах отобразится адрес, телефонный номер и дата рождения этого покупателя.

Существует множество способов создать объект, который будет использоваться как data source для binding'а. Многие люди создают объект в коде и присваивают свойству DataContext у Window этот объект. Вообще, это хороший способ. Вы могли заметить, что я добавляла объект-источник в Resource Dictionary класса Window в большинстве моих постов, и это работало довольно хорошо. Однако, у нас есть класс ObjectDataProvider в data binding'е, который так же может быть использован для создания вашего source-объекта в XAML. В этом посте я попытаюсь объяснить различия между добавлением объекта-источника непосредственно в resources и использованием ObjectDataProvider. Надеюсь, я предоставлю вам руководство о том, как оценить вашу задачу и выбрать наилучшее решение.

Доброй ночи Хабра-сообщество.
Я только что получил инвайт к вам в компанию, и сразу же решил написать что-то, что возможно окажется для кого-то полезным… Не судите строго.

Я являюсь одним из разработчиков одного Open Source проекта, одной из основных частей которого является графический редактор, который должен сохранять векторную графику в формате XAML в рамках объектной модели WPF. В процессе разработки, я столкнулся с проблемой. Bindings, созданные из кода ,(или из загруженного XAML файла) не сохраняется обратно в XAML при попытке сериализации стандартным XamlWriter. Как оказалось это стандартное поведение XamlWriter описанное в MSDN. Я пытался найти решение в сети, но нашёл только одну статью на CodeProject. К сожалению, как оказалось, это решение не подходит для сложных XAML документов по ряду причин. Я уже начал рассматривать вариант написания собственного сериализатора, когда увидел, что расширение TemplateBinding прекрасно сохраняется стандартными средствами, это меня натолкнуло на мысль, что ещё не всё потеряно, и вооружившись Reference Source Code от MS и дебагером я начал изучать проблему. И вот что у меня вышло.

Когда я впервые познакомился с техникой связывания переменных, то в первое время хотелось связывать всё подряд, настолько это было увлекательно. Как и любую технологию, JavaFX и binding не следует применять бездумно. Следует помнить, что binding в сущности спрятанная реализация паттерна Observer (или Listeners, кому как больше нравится). Как следствие, может возникать множество не очевидных проблем, таких как «утечки памяти», проблемы с производительностью и т.п.

В этом посте хотелось бы привести ряд паттернов и антипаттернов применения binding'а в JavaFX. Кроме того, второй задачей является опубликовать ответы на некоторые вопросы, которые часто задавали на Sun Tech Days, когда я «дежурил» на стенде JavaFX. Мне кажется, что многие подобные вопросы плохо освещены, и в рунете особенно.

На этот раз хотелось бы расширить предыдущую статью про bind небольшим дополнением про двунаправленный bind (bind with inverse).

В отличие от обычного связывания переменной, bind with inverse позволяет не только связать одну переменную с другой, но и создать двунаправленное соотношеие между переменными.

Приложение не отвечает?!

Многие из тех, кто программирует WPF-приложения, наверное тысячи раз писали конструкцию вида:

{Binding Items}

Если получение элементов коллекции Items выполняется в основном потоке приложения и занимает некоторое время — мы получаем «мертвый» пользовательский интерфейс. Приложение некоторое время не будет отрисовывать изменения состояния и реагировать на пользовательский ввод.

Привязка данных(binding) является достаточно удобным средством ASP.NET MVC. Удобно оно в первую очередь тем, что позволяет скрыть реализацию преобразования данных между данными из модели и данными HTTP запроса.
В своих проектах я часто сталкиваюсь с необходимостью сохранять различные данные типа blob и image. В этой статье я бы хотел показать, как можно легко организовать и использовать привязку данных из модели, которые содержат различные изображения. Для примера я взял учебный проект MVC Music Store и решил его подправить — добавить возможность изменять изображение обложки музыкального альбома. При написании данной статьи, я использовал версию APS.NET MVC 3 и Razor.

При разработке DXScheduler for WPF мы получили от пользователя сценарий, в котором использовался MVVM шаблон.
Пользовательский объект назначался свойству DataContext нашего планировщика, а в XAML-разметке осуществлялась «привязка» к соответствующим свойствам объекта с использованием Binding-выражений.
Но возникла проблема — планировщик содержал некий невизуальный объект Storage, который хранил набор настроек для данных. В том виде, в котором были записаны Binding-выражения, свойства объекта-стораджа не обновлялись.

О том, как была решена эта проблема, вы узнаете ниже…

Просто и быстро

Не так давно я столкнулся с необходимостью запротоколировать список изменений в нашем ПО. Заказчик прислал мне формуляр, который я должен был заполнить в соответствии с их внутренними требованиями к документации. Я открыл прилагавшийся к письму файл «Изменения 1.xls» и немного приуныл. Точнее, мне в голову последовательно пришли мысли об увольнении, а затем — о самоубийстве. Формуляр состоял из 14 колонок. Быстро перемножив в уме количество колонок с числом внесенных нами атомарных изменений (около пятисот), я пошел курить.
Сделать такую работу руками мне не под силу. Большинство данных (номера новых версий, описания изменений и т. п.) у меня, конечно, имелись в наличии, но в разных местах и самых причудливых форматах. Но семьсот копипастов — увольте. Поэтому мне пришлось немного освоить PyUNO. На всякий случай — опишу вкратце процесс управления документом OOo из питоновского биндинга, вдруг кому пригодится.

Некоторое время назад мне в голову пришла мысль создать библиотеку для быстрой генерации форм на Java Swing. Расскажу, как я к этому пришел.

Сейчас появляются новые модные языки использующие парадигму функционального программирования. Тем не менее, в обычной Java
можно использовать функции для описания поведения объектов. Причём делать это можно полностью в рамках синтаксиса Java.

Я опубликовал Java-библиотеку позволяющую связывать (binding) объекты через функции (см. https://code.google.com/p/tee-binding/ )

Привет, Хабр!

В предыдущей статье я провёл некий ликбез по внутренностям Flex-компилятора (по части MXML) и рассказывал, как избавить себя от проблем работы с классами в MXML, требующими параметры конструктора. Сейчас мы разберём другую сторону вопроса — установка параметров в custom-значения (к примеру, константы) без использования механизма Binding (хотя, очень похоже на него).

Использование такого компонента как BusyIndicator привнесит в наше приложение приятные (индикация процесса) и полезные (блокировка элемента управления) качества. Однако до последнего времени я редко использовал его, т.к. при асинхронном получении источника данных приходилось постоянно писать дополнительный код для включения/выключения. При синхронной работе ситуация вроде как упрощается, но использование MVVM-модели всё-равно требует дополнительных телодвижений. Особенно, если BusyIndicator добавляется в самом конце разработки формы.

Поэтому, я решил максимально автоматизировать этот процесс, чтобы мне не приходилось писать ни строчки кода. Итак:

Данная статья является продолжением статьи Автоматический BusyIndicator для асинхронных операций и не только.

В топике SASS против LESS хабраюзер morr упомянул интересный libsass — реализацию SASS на C++

На минувшем Railsconf 2012 был отдельный доклад про sass, где анонсировали фичи над которыми сейчас ведётся работа, и которые появятся в следующем релизе:
1. libsass — написанный на C компилятор sass в css, работающий быстрее на порядки нынешнего скрипта на руби. Для крупных проектов это очень существенно — большие объёмы стилей при деплое компилируются ну очень долго(полминуты и дольше). Так же это позволит написать биндинги для libsass к другим языкам, что означает более простое встраивание sass во фрейморки питона/ноды/дотнета/пхп.
…

А я взял и сделал для libsass биндинги для Python. Встречайте, любите и пользуйтесь python-sass

ObjectScript — новый встраиваемый объектно-ориентированный язык программирования с открытым исходным кодом. ObjectScript расширяет возможности таких языков, как JavaScript, Lua и PHP.

По результатам предыдущих статей было много вопросов о том, как подключать свои классы и функции на C++ к ObjectScript. Имеющийся в первых сборках OS способ подключения едва ли удовлетворял потребности и я решил сделать более мощный и удобный биндинг, который теперь идет в комплекте с OS поумолчанию.

В чем собственно преимущество нового биндинга: теперь можно подключать любую функцию, с любыми параметрами, любым возвращаемым значением без дополнительных оберток. Сразу подключаете ту функцию, которая у вас есть и все, готово.

Впервые прочитав знаменитую статью Джоша Смита WPF Apps With The Model-View-ViewModel Design Pattern я был очень вдохновлен философией MVVM и решил все будущие проекты писать исключительно с ее использованием. По мере «внедрения» MVVM я столкнулся с определенными трудностями и недостатками (на мой субъективный взгляд). В одном из проектов мне был необходим UserControl, который бы позволял авторизироваться на веб-сервисе. При попытке забиндить свойство ViewModel к элементу управления PasswordBox я получил такую ошибку:
A 'Binding' cannot be set on the 'Password' property of type 'PasswordBox'. A 'Binding' can only be set on a DependencyProperty of a DependencyObject