Better User and Developer Experiences – From Windows Forms to WPF with MVVM: Part 6, Templating

In order to rethink how we architect and write client applications, there is one last important concept Windows Presentation Foundation introduces, beyond the excellent Data Binding and Commanding support I’ve already discussed.  WPF adds an entire suite of features specifically related to Styling and Templating.  This is often discussed in relation to improving the overall look, feel, and usability of applications written using WPF – the key to the new user experience (UX) WPF allows.  However, the templating engine introduced with WPF has other side effects, which change the way we should design our software, not just change the way we stylize our software.

Windows Presentation Foundation, in its design, strives to keep a clear separation of presentation and logic.  This is apparent throughout its architecture, but perhaps most notable in one of the core building blocks of every WPF application: the Control class. 

Controls, in WPF, have two completely separate parts.  There is the logical portion, and then there is a ControlTemplate that defines how the control is represented visually; how the control looks.  The difference in thinking, even in this core element, is apparent from the documentation.

Here is how the Control class in Windows Forms is described in MSDN:

Defines the base class for controls, which are components with visual representation.

Compare that to the Control class in WPF:

Represents the base class for user interface (UI) elements that use a ControlTemplate to define their appearance.

Note the difference here.  Even the most basic definition of a “Control”, the core component used to build applications, has changed in Windows Presentation Foundation.  In Windows Forms, when you defined a control, you defined everything about the control directly.  Take a button – a button not only had to deal with the fact that it has behavior (its something visual on which you click, which in turn triggers behavior) – it also directly handled its own rendering.  Typically, if you wanted to make a Button that looked dramatically different from the standard button, you’d make a custom control (ie: a separate class), where you’d handle, not only the button’s behavior, but also all of the code required to paint the customized button.  In WPF, making custom controls is much less common – instead of making a separate class for the new button, you could just make a custom Style, a ControlTemplate which completely changes the way the button is rendered.  However, the behavior of the button is the same, since it’s still uses the standard “Button” class.

This is the key to making WPF applications highly designable – it’s very easy to allow a designer to go in and completely customize the look and feel of every part of your application without introducing custom controls.  Many people tout this as WPF’s advantage over Windows Forms, as well as nearly every other preceding UI technology.

In our case, however, we’re interested in how to architect our application from a code standpoint, not how to make it pretty.  The styling and templating engine in WPF provides another very critical component: the DataTemplate.

Data templates are most often used by WPF controls whose purpose is to display a collection of items.  These typically are the classes that derive from ItemsControl, such as ListBox and TreeView.  For our purposes, lets look at ListBox.

In Windows Forms, when you had a ListBox, by default it just displayed a list of items as text.  Changing this required creating an owner drawn list box, which was a challenge, even for a simple change in style.  This requires handling your own GDI+ drawing using the Graphics class, and pushed everything into code that is difficult to write and maintain.

In WPF, this is handled by a DataTemplate.  By default, you can bind a collection of any objects to a ListBox, and the ListBox will list the results of calling Object.ToString() on each element of the collection.  Custom drawing is handled very easily by using a DataTemplate.  In the Styling and Templating example, the DataTemplate creates a Border with a nested Image, bound to the Source property of each element.  This causes the ListBox to display a list of Images.

In our RSS Feed Reader, we use the same technique to display a list of FeedItems.  Our ListBox is bound directly to a list of our RssModel.FeedItem class, and without a DataTemplate, we see:

However, in our UserControl, we added a very simple DataTemplate:

<DataTemplate DataType="{x:Type model:FeedItem}">
    <TextBlock Text="{Binding Path=Title}" />
</DataTemplate>

This causes our display to change.  Now, instead of just listing the class name (the default behavior of ToString() on our RssModel.FeedItem class), we display a TextBlock containing the FeedItem’s Title property:

This is much nicer, and very simple to implement. 

DataTemplates, however, go far beyond just displaying Text – we could have displayed borders, images, text, or any other complex item we wished, merely by specifying a template in our UserControl.  The idea behind a DataTemplate is that you specify, in XAML, how any object should be represented visually.  This lets us tell the user interface to directly render a custom class, without the code needing to know or worry about the class being rendered properly.

In our case, we used that to customize the display of a list of FeedItems.  The MSDN sample displayed a list of Photo classes using pictures surrounded by a border.  This flexibility is the key to rethinking our architecture, and in our final installment, I’ll delve into how and why this should change the way you think about designing client applications.

… Continued in Part 7, MVVM …