d:DesignInstance in Blend 4

Christopher Bennage — Mon, 29 Mar 2010 20:12:00 GMT

Let’s walk through an example of using d:DesignInstance for improving the design-time experience in Blend. For background, see my last post on the topic.

I’m going to be using the ContactManager sample from the Caliburn trunk. You can access the source of it here under: \trunk\samples\LOB Samples\Silverlight\ContactManager\

We’re only going to concern ourselves with one view/viewmodel pair:

ContactListView
ContactListPresenter

(This sample code still uses Caliburn’s old naming scheme that was influenced by the MVP pattern. “Presenter” here means “View Model” for all practical purposes.)

ContactListView displays a list of contacts in an ItemsControl on left side of the view. As you can see, there isn’t much visible in Blend.

On the corresponding viewmodel, we have a property named Contacts that we’ll bind to the ItemsControl.

(Note that Caliburn is binding to this property using naming conventions, but we’ll need to add an explicit binding in order to play nice with Blend.)

Here’s what my ItemsControl looks like:

<ItemsControl x:Name="Contacts" 
              ItemsSource="{Binding Contacts}">
<!-- omitted for brevity -->
</ItemsControl>

Let’s select the ItemsControl in Blend and examine the data binding for the ItemsSource.

It’s a sad, empty little dialogue that greets us.

Getting the Shape of Our Data Context

Let’s open up the XAML for ContactListView. In the root element, we’ll set the design-time data context using the d:DesignInstance markup extension. It looks like this:

<UserControl xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:Controls="clr-namespace:Caliburn.Silverlight.ApplicationFramework.Controls;assembly=Caliburn.Silverlight.ApplicationFramework"
             xmlns:rm="clr-namespace:Caliburn.PresentationFramework.RoutedMessaging;assembly=Caliburn.PresentationFramework"
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
             mc:Ignorable="d" x:Class="ContactManager.Views.ContactListView"
             xmlns:local="clr-namespace:ContactManager.Presenters"             
             Height="400"
             Width="750"
             d:DataContext="{d:DesignInstance local:ContactListPresenter}"
             rm:Message.Attach="[Event Loaded] = [Action LoadContacts]">

<!-- omitted for brevity -->
</UserControl>

Wow, that’s a lot of namespaces. We’re only concerned with two lines though. The first one is

    xmlns:local="clr-namespace:ContactManager.Presenters"

This also use to reference our local type in XAML.

The second is

    d:DataContext="{d:DesignInstance local:ContactListPresenter}"

This tells Blend that we want to use the ContactListPresenter for our design-time data context. However, this doesn’t create an instance of the type and we won’t see any data appear in Blend. Instead, this tells Blend what the “shape” of our data context is. In other words, Blend uses reflection to learn about the properties so that it can show us a lot more in the data binding editor.

Let’s open that up again.

Much less depressing. This also means that when I drill down and edit the ItemTemplate, Blend is aware of the data context and I get support for bindings there as well. Booya.

Getting Some Sample Data

I said earlier that d:DesignInstance does not create an instance of the specified type. You can make it create an instance though by setting the IsDesignTimeCreatable property to true. Now, we don’t want to do this with ContactListPresenter because it has a couple of dependencies injected into it’s constructor. So in order to provide a little sample data for the designer, I’ve created a new class to use as my design-time viewmodel:

public class SampleContactListPresenter
{
    public List<Contact> Contacts {get;set;}    
    
    public SampleContactListPresenter()
    {
        Contacts = new List<Contact>
        {
            new Contact{ FirstName="Ford", LastName="Prefect"},
            new Contact{ FirstName="Author", LastName="Dent"},
        };
    }
    
}

I could have derived this from ContactListPresenter, but that would have been a lot of unnecessary work. A better choice would be for my design-time viewmodel and my real viewmodel to implement a common interface. That would help them maintain the same shape. (An even better choice would be to use d:DesignData, but that’s another post).

In this case, I decided to keep it really simple.

After adding this class, I need to change the line in my XAML that creates the design-time data context to this:

d:DataContext="{d:DesignInstance local:SampleContactListPresenter, IsDesignTimeCreatable=True}"

and now I can see some sample data in Blend:

N.B. I discovered after I worked through this that the ContactListPresenter in the trunk doesn’t get along well with d:DesignInstance. I haven’t isolated the exact problem yet, but you’ll need to modify the class if you want to follow along with this tutorial. Change the class so that it is only inheriting from ScreenConductor<IContactDetailsPresenter>:

public class ContactListPresenter : ScreenConductor<IContactDetailsPresenter>, IContactListPresenter

Exploring Design-Time Data in Blend 4

Christopher Bennage — Fri, 26 Mar 2010 20:26:00 GMT

I’ve gleaned most of what I have learned about this topic from Unni, Karl, and Jack. I recommend checking out their posts for additional information.

d:DataContext

The d:DataContext attribute allows you to establish a data context that is only for design time. You can use it the same way (more or less) that you use the real DataContext. Two options are available for providing data for the design-time data context. They are the markup extensions d:DesignInstance and d:DesignData.

{d:DesignInstance}

This new markup extension has three properties:

Type	The type of the instance that we would like to use for design-time data context. This is the default property, so you can omit it and just provide the type value.
IsDesignTimeCreatable	True: create an instance of the type and use it for the design-time data. False: reflect over the type so that the data binding expression builder is aware of the members.
CreateList	Do we want a list of instances or a single instance?

This is mostly for giving you the shape of the data that you are binding to. Though you will see the actual property values at design-time, so you can create a new type with the same shape as your real viewmodel, but with data to use for design-time (perhaps by interface, perhaps by subclassing). This approach can be tedious though, especially in cases where you need lists in design-time data.

{d:DesignData}

This markup extension has a single property, Source, that points to a xaml file describing the design-time data. The best way to create this xaml file is using Blend. Blend can automatically generate Lorem Ipsum for your viewmodels (which is kinda cool). I’ll show you how to do that in a follow-up post.

N.B. While everything works brilliantly in Blend, I wasn’t able to get d:DesignData to work for Silverlight in Cider (Visual Studio 2010), it complained about the leading forward slash (/) but still didn’t work when I removed it. However, removing the forward slash broke it for Blend.

A Quick Example

<UserControl x:Class="DesignTimeTest.MyView"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
             mc:Ignorable="d"
             xmlns:local="clr-namespace:DesignTimeTest"
             d:DesignHeight="300"
             d:DesignWidth="400"
             d:DataContext="{d:DesignInstance local:MyViewModel, IsDesignTimeCreatable=True}" />

More on d:DesignInstance

Christopher Bennage : Silverlight, Blend