I must admit that the title of this post is not entirely clear, however I couldn't find a way to sum up the content in one short sentence, so we'll dive straight into an example. Let's say for example you have developed a funky little business-card as illustrated above, using the simple XAML below:
The above XAML creates a simple visual layout that binds to the Name, Email, Web and Company properties of the data object which is presented to the inherited DataContext. Nice and simple.
Now, let's say you want to re-use this XAML markup in a number of places across your application. The obvious solution is to package it within a UserControl. However, elsewhere within the application contact details are stored in different types, with different properties, perhaps the property Web is used in some places, whereas the property URL is used elsewhere. If our UserControl simply contains the XAML markup given above, the binding paths are hard-coded and inflexible. So, how do we package the above markup for re-use whilst maintaining flexibility?
In UI frameworks which do not support databinding the obvious choice would be to define an interface IContactDetails, which defines a compile-time contract that clients of the control must implement on their business objects. This would allow us to enforce the presence of properties with specific names. However, with WPF / Silverlight the binding framework removes the need for controls to demand the presence of a certain interface and life is now much better as a result!
So ... what we really want here is to allow the clients of our ContactDetails user control to provide bindings for the various framework elements within the user control itself.
Bindings can be constructed in code-behind by invoking the SetBinding method defined on DependencyObject as show in the example below:
Therefore, if we were to expose the various Bindings as properties of the control (hence this blog post's title), we could set the name, email, web elements binding accordingly using the Setbinding method.
The first time I tried this I added a NameBinding dependency property of type Binding to my UserControl, so that the client XAML looked as follows:
However, this didn't quite have the desired effect. When the XAML reader processes the above markup it creates the Binding object that we are after, however it does not set the NameBinding property value to this binding. Instead, it uses it to bind the NameBinding property.
The solution to the problem is to make NameBinding a standard CLR property. This time when the XAML reader encounters the above markup it once again creates the Binding object, but since NameBinding is not a dependency property it does not use it to bind the property, it simply sets the property value.
The code-behind of our ContactDetails user control looks like this:
The four bindings are exposed as CLR properties. When the UI is Loaded, we use them to bind the various elements within the control. The net result is that we now have a re-useable control whilst maintaining the flexibility provided by the binding framework, as illustrated by its usage below:
Now for another example and a bit more fun ...
The above Silverlight application shows a number of particles exhibiting Brownian motion.
This application creates 50 instances of a Particle object within an ObservableCollection:
The particles are rendered by a ScatterControl, which is a UserControl:
This control has an ItemsSource property of type IEnumerable, and exposes three other properties of type Binding.
The markup for this control is given below:
The particles are rendered using an ItemsControl, which creates an instance of an Ellipse for each bound particle and places it within a Canvas (As defined by the ItemsControl.ItemsPanel property). As each ellipse is loaded, we set the bindings in code-behind:
Again, by exposing Bindings as properties this user control is just as flexible as if its markup was included in the page directly. This example also illustrates another interesting point, the Bindings that the client provided have been re-used for each Ellipse that was created by the ItemsControl. This is made possible because when SetBinding is invoked on our Ellipse, the Binding is not associated with the Ellipse, rather, it is used to create an instance of a BindingExpression. Binding is used to declare a binding, whereas BindingExpression is the implementation, i.e. it does the heavy-lifting of copying data to-and-from from source to target (and vice-versa).
You can download the full source for both examples: bindingproperties.zip
Regards, Colin E.