Bring Your Data to Life with WPF Session

The premise behind this session is the idea of separation of UI designers and developers. The UI people don't know how to code business rules. But the UI people need to be able to 'try out' the user interface and easily make changes. This is the designer/developer separation that is in the Web space, only in this case, it's for Windows Forms applications.

For those of you who aren't aware, one of the drawbacks of WPF is the lack of data binding support. This is a significant step back in functionality, if you're used to creating ASP.NET or Windows Forms apps. And it stopped me from using WPF to any great extent.

The session starts out slow, talking about the rationale behind data binding. This is something that I would expect most developers to be aware of, although if he's including designers in his target audience, then I can understand the digression.

Databinding in a WPF form can be done through the latest version of Expression Blend. A new Data pane allows for the selection of a data source (a class, for example). Once the data source has been specified, the property sheet for a control allow the mapping between the control's property and the data source's property to be made. This is a familiar process, although very new to WPF and Expression Blend.

WPF includes the concept of a value converter. This is a function that operates on a bound value with the result from the conversion being displayed. As well, the data binding appears to be hooked up to the property change notification mechanism, in that if a property is programmatically changed, the updated value appears in the form.

There is also a mechanism (INotifyCollectionChanged) which raises an event when the collection is changed. The idea of 'change' in a collection is the addition or removal of an item from the collection. WPF data binding is able to detect and respond to these events.

WPF has replaced the ObjectDataSource class with an ObjectDataProvider. Without seeing the details, I'm guessing there is a lot of similarity in terms of functionality, if not the details.

In the WPF itself, the binding notation looks like the following

<TextBox Test="{Binding Path=Sun.Name, Source={StaticResource solarSystem}}" />

This notation takes the Name property of the Sun object found in the ObjectDataProvider named solarSystem. A little cumbersome, but since it's definable through Expression Blend, that's only an issue for those of you who code in Notepad 2008.

As part of the data binding mechanism, there is the concept of a data template. This greatly resembles a template within ASP.NET, where different fields and controls are displayed based on the mode of the control. One twist is that WPF data templating can be defined based on the type of object being displayed. Within the same list box, a collection of Products will appear with different fields then a collection of Customers, even though the underlying WPF is the same.

The final reveal for the demo is a list box that displayed the information about a solar system not as a list of planet names, but as a graphical representation of the solar system orbit with the images of the planets and the positioning away from the sun based on properties from the object. The cool part is that there is no change to the underlying object necessary to change from a drop down list of properties to the graphical view. Only the XAML needs to be modified. But again, that is the power of WPF.

One word of warning. Not all of the advances in WPF are necessarily available in Silverlight. A concept called a CollectionView was explicitly called out as not being part of Silverlight 2. So if you are developing for the Silverlight market, make sure that the data binding techniques you use are supported before you spend time on it.

WPF provides support for a hierarchical data template. This template because useful when you are trying to create a tree view visualization for your data. It's similar to the list box data template in concept, but the level within the hierarchy becomes part of the mechanism for distinguishing between the different data fields and styles that are used.

It looks to me like data binding for WPF has finally moved towards the standards that we have been used to. The presentation didn't cover error providers and error notification, but a slide at the end suggests that it is, using the IDataErrorInfo interface.