I have recently been playing around with Knockout.js, and have been hugely impressed with just how clever it is, and how intuitive. One of the really great features that Knockout provides is the ability to have a computed observable object. That’s a fancy way of saying that it has functionality to update when objects that it is observing update. Borrowing an example from the Knockout website, this simply translates into code like this:
function AppViewModel() {
this.firstName = ko.observable('Bob');
this.lastName = ko.observable('Smith');
this.fullName = ko.computed(function() {
return this.firstName() + " " + this.lastName();
}, this);
}
So, whenever firstName or lastName change, the fullName automatically changes as well.
Wouldn’t it be great if we could do this in WPF as well? I would love it if MVVM allowed you to update one property and have all dependent properties update with it – currently, if you have a dependent property, then you have to update that manually.
Well, Dan Vaughan has an amazing implementation of this functionality over on his site, and it’s quite astounding code – he really does have the brain the size of a planet. Being a simpler person though, I had to wonder if there was a simpler way that didn’t involve rewriting a lot of old ViewModels, and the word that kept coming to my mind is MarkupExtension. For those of you who don’t know what a MarkupExtension is, it’s a way to let XAML know that it has something to do that’s a little bit special – you’ve probably already used some even without knowing it – if you’ve used StaticResource, DynamicResource or Binding, then you’ve used a MarkupExtension.
So, having thought it through from a few different angles, it seemed as though a MarkupExtension will do the job – and surprise surprise, it does. Before I go into the code, though, I’m going to share some code with you that you will definitely find handy if you write your own extensions that rely on the DataContext. Basically, because of the different places and ways you can declare a DataContext, I wanted some code that I could use to cope with the DataContext not being present when we fired off our extension.
So, let’s break down that extension first. Unsurprisingly, we’re going to make this an abstract extension, as it’s not much use on its own – it’s a great way to support other extensions, but it does nothing useful that we’d want to hook into in the XAML:
public abstract class DataContextBaseExtension : MarkupExtension
If you notice, we are inheriting from MarkupExtension – this is vital if we want to be able to use this as an extension. Now, by convention, extensions always end in Extension, but we don’t have to include that when we declare it in the XAML. Even though we don’t directly use this class in XAML, it’s good to name it this way so that we preserve the intent.
Next, we are going to declare some properties that we will find useful later on.
protected object TargetObject { get; set; }
protected object TargetProperty { get; set; }
protected DependencyObject TargetObjectDependencyObject { get; set; }
protected DependencyProperty TargetObjectDependencyProperty { get; set; }
protected object DataContext { get; private set; }
Don’t worry about what they do yet – we’ll cover them more as we examine the code. Assigning these properties is taken care of in the overridden MarkupExtension.ProvideValue implementation:
public sealed override object ProvideValue(IServiceProvider serviceProvider)
{
IProvideValueTarget target = serviceProvider.GetService(typeof(IProvideValueTarget))
as IProvideValueTarget;
if (target != null)
{
TargetObject = target.TargetObject;
TargetProperty = target.TargetProperty;
TargetObjectDependencyProperty = TargetProperty as DependencyProperty;
TargetObjectDependencyObject = TargetObject as DependencyObject;
if (!FindDataContext())
{
SubscribeToDataContextChangedEvent();
}
}
return OnProvideValue(serviceProvider);
}
As you can see, assigning these values is straight forward, but we start to see the meat of this class now. By sealing this method, we ensure that we cannot override it (giving us a stable base for this class – we can’t accidentally forget to call this implementation), which means that we have to provide a way for derived classes can do any processing that they need as well. This is why we return an abstract method that derived classes can hook into to do any further processing:
protected abstract object OnProvideValue(IServiceProvider serviceProvider);
Now, this method is only fired once, which means the DataContext could be set long after this code has finished. Fortunately, we can get round this by hooking into the DataContextChanged event.
private void SubscribeToDataContextChangedEvent()
{
DependencyPropertyDescriptor.FromProperty(FrameworkElement.DataContextProperty,
TargetObjectDependencyObject.GetType())
.AddValueChanged(TargetObjectDependencyObject, DataContextChanged);
}
But how do we actually find the DataContext? Well, this is straightforward as well:
private void DataContextChanged(object sender, EventArgs e)
{
if (FindDataContext())
{
UnsubscribeFromDataContextChangedEvent();
}
}
private bool FindDataContext()
{
var dc = TargetObjectDependencyObject.GetValue(FrameworkElement.DataContextProperty) ??
TargetObjectDependencyObject.GetValue(FrameworkContentElement.DataContextProperty);
if (dc != null)
{
DataContext = dc;
OnDataContextFound();
}
return dc != null;
}
private void UnsubscribeFromDataContextChangedEvent()
{
DependencyPropertyDescriptor.FromProperty(FrameworkElement.DataContextProperty,
TargetObjectDependencyObject.GetType())
.RemoveValueChanged(TargetObjectDependencyObject, DataContextChanged);
}
The only things of any real note in there is that, once the DataContext is found in the event handler, we disconnect from the DataContextChanged event and call an abstract method to let derived classes know that the DataContext has been found.
protected abstract void OnDataContextFound();
Right, that’s our handy DataContextBaseExtension class out the way (hold onto it – you might find it useful at some point in the future). Now let’s move onto the extension that does the markup mojo. This class adheres to the convention of ending in Extension:
public class ComputedObservableExtension : DataContextBaseExtension
Now, we want to provide the ability for the user to use a parameter name, or to have one automatically applied if we leave it out. You’ve seen this behaviour when you’ve done {Binding Name} or {Binding Path=Name}. In both cases, Path was being referred to, but MarkupExtensions are clever enough to work this out. To do this, we need to supply two constructors, and use something called a ConstructorArgument to tell the extension that a particular property is being defaulted.
public ComputedObservableExtension()
: this(string.Empty)
{
}
public ComputedObservableExtension(string path)
: base()
{
this.Path = path;
}
[ConstructorArgument("path")]
public string Path
{
get;
set;
}
We are going to use Path to refer to the computed property. We also need something to tell the extension what properties we are going to observe the change notification on:
public string ObservableProperties
{
get;
set;
}
I’m not being fancy with that list. In this implementation, you simply need to supply a comma separated list of properties to this method. Now, we are going to hook into the override OnProvideValue method to do a little bit of processing at the startup of this class.
protected override object OnProvideValue(IServiceProvider serviceProvider)
{
if (TargetProperty != null)
{
targetProperty = TargetProperty as PropertyInfo;
}
if (!string.IsNullOrWhiteSpace(ObservableProperties))
{
string[] observables = ObservableProperties
.Replace(" ", string.Empty)
.Split(new char[] { ',' }, StringSplitOptions.RemoveEmptyEntries);
if (observables.Count() > 0)
{
observedProperties.AddRange(observables);
UpdateProperty(ComputedValue());
}
}
return string.Empty;
}
Basically, we start off by caching the TargetProperty as a PropertyInfo. We’ll make heavy use of this later on, so it removes a bit of reflection burden if we already have the PropertyInfo at this point. Next, we split the list of observed properties up into a list that we will use later on. The UpdateProperty method is used to actually update the computed property on the screen, so let’s take a look at that next.
private void UpdateProperty(object value)
{
if (TargetObjectDependencyObject != null)
{
if (TargetObjectDependencyProperty != null)
{
Action update = () => TargetObjectDependencyObject
.SetValue(TargetObjectDependencyProperty, value);
if (TargetObjectDependencyObject.CheckAccess())
{
update();
}
else
{
TargetObjectDependencyObject.Dispatcher.Invoke(update);
}
}
else
{
if (targetProperty != null)
{
targetProperty.SetValue(TargetObject, value, null);
}
}
}
}
As you can see, this code simply sets the value – either using the DependencyProperty and DependencyObject that we first obtained in the base class, or by updating the standard property if the DP isn’t present.
The ComputedValue method is responsible for retrieving the value from the underlying DataContext.
private string ComputedValue()
{
if (DataContext == null) return string.Empty;
if (string.IsNullOrWhiteSpace(Path)) throw new ArgumentException("Path must be set");
object value = GetPropertyInfoForPath().GetValue(DataContext, null);
if (value == null)
return string.Empty;
return value.ToString();
}
private PropertyInfo propInfo;
private PropertyInfo GetPropertyInfoForPath()
{
if (propInfo != null) return propInfo;
propInfo = DataContext.GetType().GetProperty(Path);
if (propInfo == null) throw new InvalidOperationException
(string.Format("{0} is not a valid property", Path));
return propInfo;
}
We seem to be missing a bit though. If you thought that, you would be right – the bit that’s missing is what happens when we find the DataContext. Well, when we have a DataContext, we use the fact that it has implemented INotifyPropertyChanged to our own advantage.
protected override void OnDataContextFound()
{
if (DataContext != null)
{
propChanged = DataContext as INotifyPropertyChanged;
if (propChanged == null)
throw new InvalidOperationException
("The data context item must support INotifyPropertyChanged");
UpdateProperty(ComputedValue());
if (TargetObject != null)
{
((FrameworkElement)TargetObject).Unloaded += ComputedObservableExtension_Unloaded;
}
propChanged.PropertyChanged += propChanged_PropertyChanged;
}
}
void ComputedObservableExtension_Unloaded(object sender, RoutedEventArgs e)
{
if (TargetObject != null)
{
((FrameworkElement)TargetObject).Unloaded -= ComputedObservableExtension_Unloaded;
}
propChanged.PropertyChanged -= propChanged_PropertyChanged;
}
void propChanged_PropertyChanged(object sender, PropertyChangedEventArgs e)
{
if (observedProperties.Count == 0 || string.IsNullOrWhiteSpace(e.PropertyName) ||
observedProperties.Contains(e.PropertyName))
{
UpdateProperty(ComputedValue());
}
}
And that’s pretty much it – that’s all we need to give the XAML the markup that we wanted.
But, what does our MVVM code look like now? Well, let’s start with a familiar POCO VM:
public class PersonViewModel : INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged;
private string firstName;
private string surname;
private int age;
public string Firstname
{
get { return firstName; }
set
{
if (firstName == value) return;
firstName = value;
Notify("Firstname");
}
}
public string Surname
{
get { return surname; }
set
{
if (surname == value) return;
surname = value;
Notify("Surname");
}
}
public int Age
{
get { return age; }
set
{
if (age == value) return;
age = value;
Notify("Age");
}
}
public string Details
{
get
{
return firstName + " " + surname + " is " + age.ToString();
}
}
private void Notify(string prop)
{
PropertyChangedEventHandler handler = PropertyChanged;
if (handler == null) return;
handler(this, new PropertyChangedEventArgs(prop));
}
}
Now, let’s attach it to our main window.
public partial class MainWindow : Window
{
private PersonViewModel person;
public MainWindow()
{
InitializeComponent();
person = new PersonViewModel { Age = 21, Firstname = "Bob", Surname = "Smith" };
DataContext = person;
}
}
As you can see – we’ve put no magic in here. It’s just a simple VM. So, what does the XAML look like?
<Window x:Class="ComputedObservableExtensionExample.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:co="clr-namespace:ComputedObservableExtensionExample"
Title="Computed ObservableExample" Height="350" Width="525">
<Window.Resources>
<Style TargetType="{x:Type TextBlock}">
<Setter Property="FontSize" Value="13.333" />
<Setter Property="HorizontalAlignment" Value="Left" />
<Setter Property="VerticalAlignment" Value="Center" />
</Style>
<Style TargetType="{x:Type TextBox}">
<Setter Property="FontSize" Value="13.333" />
<Setter Property="HorizontalAlignment" Value="Stretch" />
<Setter Property="VerticalAlignment" Value="Center" />
<Setter Property="VerticalContentAlignment" Value="Center" />
<Setter Property="Margin" Value="2" />
</Style>
</Window.Resources>
<Grid>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="100"/>
<ColumnDefinition />
</Grid.ColumnDefinitions>
<Grid.RowDefinitions>
<RowDefinition Height="30" />
<RowDefinition Height="30" />
<RowDefinition Height="30" />
<RowDefinition Height="30" />
</Grid.RowDefinitions>
<TextBlock Text="Firstname" Grid.Row="0" Grid.Column="0" />
<TextBlock Text="Surname" Grid.Row="1" Grid.Column="0" />
<TextBlock Text="Age" Grid.Row="2" Grid.Column="0" />
<TextBox Text="{Binding Firstname, UpdateSourceTrigger=PropertyChanged}"
Grid.Row="0" Grid.Column="1" />
<TextBox Text="{Binding Surname, UpdateSourceTrigger=PropertyChanged}"
Grid.Row="1" Grid.Column="1" />
<TextBox Text="{Binding Age, UpdateSourceTrigger=PropertyChanged}"
Grid.Row="2" Grid.Column="1" />
<TextBlock Text="{co:ComputedObservable Details,
ObservableProperties='Firstname,Surname,Age'}" Grid.Row="3"
Grid.Column="0" Grid.ColumnSpan="2" />
</Grid>
</Window>
And that’s it – the TextBlock with the ComputedObservable extension has been told that the Path is the Details property, and the properties that it’s observing are Firstname, Surname and Age – so changing any of those properties results in the computed property being updated as well.
Any comments, enhancements or observations, please feel to let me know. This is a first pass at this extension, and I’ve no doubt that I will be revisiting and enhancing it as I use it more and more. I will, of course, come back here and update this post as I do so.
Note – This project is a VS2012 solution, but it does not make use of any .NET 4.5 specific features, so you should be able to use the code in a VS2010 app.
The source is available here.
