Christopher Bennage : Caliburn, WPF

1 Simple Step for Commanding in Silverlight

Christopher Bennage — Wed, 03 Mar 2010 16:24:00 GMT

Silverlight 4 is now supporting the commanding that we’ve come to love from WPF. Commanding was a foundational feature for MVVM. It’s what enabled us to bind to methods on our view models.

John Papa has an excellent introductory post on using commands in Silverlight 4. This pattern is called the DelegatingCommand pattern (or sometimes RelayingCommand).

I’d like to show you the Caliburn way of handling this. I’m going to steal John’s viewmodel from the aforementioned post (and hope he doesn’t sue).

The viewmodel presents a collection of all products and a filtered collection of products. You can modify the filter by calling LoadProducts().

public class ProductViewModel
{
    public ProductViewModel()
    {
        Products = new ObservableCollection<Product>();

        AllProducts = new ObservableCollection<Product>
                          {
                              new Product {ProductId = 1, ProductName = "Apple"},
                              new Product {ProductId = 2, ProductName = "Orange"},
                              new Product {ProductId = 3, ProductName = "Banana"},
                              new Product {ProductId = 4, ProductName = "Pear"},
                              new Product {ProductId = 5, ProductName = "Grape"},
                              new Product {ProductId = 6, ProductName = "Grapefruit"},
                              new Product {ProductId = 7, ProductName = "Strawberry"},
                              new Product {ProductId = 8, ProductName = "Melon"},
                              new Product {ProductId = 9, ProductName = "Guava"},
                              new Product {ProductId = 10, ProductName = "Kiwi"},
                              new Product {ProductId = 11, ProductName = "Pineapple"},
                              new Product {ProductId = 12, ProductName = "Mango"}
                          };
    }

    public ObservableCollection<Product> AllProducts { get; set; }

    public ObservableCollection<Product> Products { get; set; }

    public void LoadProducts(string filter)
    {
        Products.Clear();
        var query = from p in AllProducts
                    where p.ProductName.ToLower().StartsWith(filter.ToLower())
                    select p;
        foreach (var item in query)
        {
            Products.Add(item);
        }
    }

    public bool CanLoadProducts
    {
        get { return true; }
    }
}

Let me point out a few notable differences between John’s original and my version of the viewmodel.

There is no ICommand property.
CanLoadProducts is a property on my model, it was a method on the original

The snippet from the corresponding view would look like this:

<StackPanel>
    <TextBox x:Name="filter" />
    <Button x:Name="LoadProducts" Content="Load" />
</StackPanel>

The Explanation

It’s binding by convention, and it is a new feature of Caliburn added after the 1.1 release^[1]. So you’ll need to get the trunk to do this.

When you have a button named LoadProducts, Caliburn will look for a method on your viewmodel named LoadProducts and automagically handle the binding for you. In addition, it will check for either a method or property (as in this example) named CanLoadProducts that it will use to toggle the enable/disabled for the button. Also, since we have a parameter named “filter” on LoadProducts, Caliburn will check to see if there is an element in the view name “filter” and pull the value from that.

There’s a great deal more that you can do with conventions (and you can even plug in your own conventions).

This also works for Silverlight 3 and WPF.

You can also see an example of this in Ayende’s sample app Alexandria.

Actually, you can do some of this in 1.0, but it is easier and much richer in the trunk. Ping the forums if you have a need to use it in 1.x.

Things I’d Like To Present

Christopher Bennage — Fri, 08 Jan 2010 11:32:00 GMT

In case you are not familiar with MIX, it is a conference from Microsoft focusing on the collaboration of design and development. Admittedly, the sessions tend to favor the developer, but there is always excellent design and UX content.

There was an open call for presentations this year and the community gets to choose which of the proposals will be selected. There are a number of excellent proposals and I encourage you to go check out the list and vote for the sessions that you are genuinely interested in. (Even if you won’t be attending, the sessions will be broadcast.)

Here are some sessions that I proposed for MIX10:

Cross Compiling Games for Silverlight & XNA

Our friend and Silverlight MVP, Bill Reiss, has created an incredible library that enables you to cross compile XNA games for Silverlight. The library is called SilverSprite and we feature it on Silver Arcade. (Wow, that’s a lot of ‘silvers’ in one paragraph.)

In this session, we’d write a simple game for XNA (discussing some of the basic of game dev along the way) and then port the game over to Silverlight.

This is an area where I wish I could spend more time. I love game development, but it’s always taking a back burner to other projects.
[vote for this]

LinqToSQL and EntityFramework Profilers: Case Study

If you aren’t already familiar with the UberProf suite of ORM profilers, you can read tales of the development on Ayende’s blog. Rob and I built the UI side of the application, and we learned a lot in the process. I’d like to do a talk were we discuss the challenges of the project, how we solved them, and what we did wrong.

Yes, NHProf will be included too. (I submitted a case study for it last year, and it didn’t get picked. I have to sneak it in).

A few interesting aspects:

we built this using MVVM, but well before Caliburn reached maturity.
the four separate apps (NHProf, EFProf, L2SProf, HProf) all use a single code base.
we’re about to port the project from WPF to Silverlight.

[vote for this]

Silver Arcade: Case Study

This is a presentation that Rob and I have made a couple of times. Most recently at the Orlando .NET Users Group. We walk through the actual code for Silver Arcade explaining the philosophy, design choices and mistakes we made along the way.

For MIX, we would focus more design and UX choices, such as the separation of the behaviors from the views. However, we like to have a lot of audience interaction and tend to follow where ever the questions led (especially those leading questions that Scott Densmore tends to ask).

Silver Arcade is also interesting because we deliberately used a number of newer hipper technologies; including Azure, ASP.NET MVC, jQuery, MEF, NHibernate and so on.
[vote for this]

Thanks!

The Influence of MVC on my WPF

Christopher Bennage — Wed, 06 May 2009 19:48:01 GMT

I was introduced to MVC as a pattern for Web development through Castle MonoRail. From there I studied a bit of Ruby on Rails (not enough) as well as the general philosophy of 37signals.

As I mentioned before, I thought I was moving away from Web development. However, the dive into ASP.NET MVC that Silver Arcade brought about has roped me back in.

My work during the day (and some nights too) is still WPF though. I’ve discovered that MVC thinking has seeped into my WPF development.

Convention Over Configuration

A characteristic of most MVC frameworks is Convention Over Configuration. In short, it means that your “environment” makes assumptions about what you want and that you only need to be explicit about the exceptions.

A practical example of this is the way that the View for an Action is inferred from the name of the Controller and Action. After creating your Action, you create a folder for the controller and and view that matches the name of the action. It just works. If you need to make exception, you can.

An Example in WPF

In our WPF development we employ a number of Separated Presentation patterns. One of the more common patterns we use is MVP (in particular, the flavor of MVP implemented in Caliburn, which is really Supervising Controller).

Imagine a simple contact manager application. We can add new contacts, view a list of all contacts, and open individual contacts for viewing or editing. We can open as many individual contacts as we like.

Let’s say that there are buttons to open up the “Add New” view and “All Contacts” view. We can open an existing contact by double-clicking on them in the “All Contacts” view.

My solution setup for this imaginary (and highly contrived) application might look like this.

ApplicationPresenter would be the root object of my UI. It would have an ObservableCollection of IPresenter that would be bound to a TabControl in Shell.xaml. Likewise, ApplicationPresenter will have a CurrentPresenter of IPresenter that will be bound to the SelectedItem on the TabControl.

Shell.xaml is my only window in this example. All of the other views are user controls. I named it “shell” because I think of it as the outermost level of the views. Shell’s data context is set to ApplicationPresenter.

I’m not going to dive too much deeper into this, because I want to get to my real point.

My presenters don’t know anything about their views. It’s up to data binding to render each presenter with the correct view. This means that I need to create data templates for each of the presenters. Not such a big deal in a small application, but it can get tedious as the application grows.

Hmmm… This structure is beginning to look a lot like an MVC app. Perhaps I can have it automatically infer my data templates for me?

Some Code

Yes we can. Here’s a very naiveté bit of code that will do just that. It makes some big assumptions:

all of your presenters implement IPresenter
all of your presenters are in a namespace containing “.Presenters”
all of your views are in an analogous namespace containing in “.Views”

Again, this is not production ready code, just my spike to prove the idea works. Please feel free to make suggestions.

public static class MvpConfiguration
{
    /// <summary>
    /// Creates a set of data templates pair to presenter classes based on naming conventions.
    /// </summary>
    /// <remarks>If a data template is already present in the resources, then it is skipped.</remarks>
    /// <param name="resources">The ResourceDictionary that the data templates for the views will be added to.</param>
    public static void InferViewsFromPresenters(ResourceDictionary resources)
    {
        var lookup = MatchPresentersToViews();

        foreach (var pair in lookup)
        {
            var template = CreateDataTemplate(pair.Value, pair.Key);
            if (resources.Contains(template.DataTemplateKey)) continue;
            resources.Add(template.DataTemplateKey, template);
        }
    }

    private static Dictionary<Type, Type> MatchPresentersToViews()
    {
        var presenters = from type in Assembly.GetExecutingAssembly().GetTypes()
                         where typeof (IPresenter).IsAssignableFrom(type)
                         select type;

        var first = presenters.FirstOrDefault();
        if (first == null) throw new Exception("I expected to find at least one presenters!");

        string viewNamespace = first.Namespace
            .Replace(".Presenters", ".Views");
        viewNamespace = viewNamespace.Substring(0, viewNamespace.IndexOf(".Views")+6);
        //yeah, that was hackish

        var views = from view in Assembly.GetExecutingAssembly().GetTypes()
                    where !string.IsNullOrEmpty(view.Namespace)
                          && view.Namespace.StartsWith(viewNamespace)
                    select view;

        var table = new Dictionary<Type, Type>();

        foreach (var view in views)
        {
            var presenter = GetPresenterForView(view, presenters);
            if(presenter == null) continue;

            table.Add(presenter,view);
        }

        return table;
    }

    private static Type GetPresenterForView(Type type, IEnumerable<Type> presenters)
    {
        string name = type.Name.Replace("View", "Presenter");
        var presenter =
            presenters.Where(p => p.Name == name).FirstOrDefault();
        return presenter;
    }

    private static DataTemplate CreateDataTemplate(Type viewType, Type dataType)
    {
        var template = new DataTemplate(dataType);

        var factory = new FrameworkElementFactory(viewType);
        template.VisualTree = factory;
        return template;
    }
}

To use this, in your App.xaml.cs within OnStartup() add:

MvpConfiguration.InferViewsFromPresenters(Resources);

What do you think? Am I totally nuts?

Oh, and I should also point out that FrameworkElementFactory is actually deprecated. :-( Caveat emptor.

Testing Bindings In WPF

Christopher Bennage — Fri, 20 Feb 2009 03:56:00 GMT

I was inspired to get off my duff and blog today by a tweet from Scott Hanselman. I didn’t really dig into the context of his tweet, but it was about TDD and WPF. In case you haven’t figured it out, I’m a big fan of WPF and TDD. Luckily, I’ve had the opportunity to work on a number of varied WPF projects (most using TDD) over the last couple of years. One problem I experienced over and over was incorrect bindings in my Xaml (as I alluded to in this post). Binding errors are silent. They sneak up on you ninja-like. If you are keeping an eye on your Output window you can catch them, but it is very easy for them to just slip by.

About two years ago, Rob and I were working on a student records application for the FSU College of Music. The system handled the entire lifecycle of a student, from application to graduation, and that involved lots of data. We had a number of screens in the app that were merely large data entry screens. Binding errors where a problem, and it seemed like a new batch showed up every time we made a release to the users.

The errors might have been the result of renaming a bound property, bad spelling, or some other such silliness. They were easy mistakes to make and thus I began to think that we really needed a way to automatically test them.

Well, I’m lazy and time passed (maybe a year) and then I mentioned it again to Rob. The next day he committed a prototype to the Caliburn trunk. (He’s like my own personal Ayende.)

Here’s an example test copied directly from Caliburn’s documentation:

public class TestBase
{
    static TestBase()
    {
        var app = new MyApplication();
        app.InitializeComponent();
    }
}

[TestFixture]
public class TestCase : TestBase
{
    [Test]
    public void Test()
    {
        var validator = Validator.For<MyUserControl, MyModel>();
        var result = validator.Validate();

        Assert.That(result.HasErrors, Is.False, result.ErrorSummary);
    }
}

In TestBase, we initialize the actual application so that we have access to application level resources. We need to this in a static constructor because we don’t want more than one instance of the application in the AppDomain.

Now, check out the Test() method. The static class Validator.For<T,K>() method returns an instance of BindingValidator<K>. The type T is some FrameworkElement that contains the bindings we’re interested in and K is the type that the FrameworkElement is bound to. Calling the Validate() method causes Caliburn to instantiate T, crawl it’s tree, and collect all the bindings. It then compares those bindings to the type K to see if they are valid. Validate() actually returns an instance of ValidationResult<K>, which is a summary of everything that Caliburn found while comparing the bindings against the actual type T.

The assertion in the test means that we expect Caliburn to find no errors, and if it does to provide us the summary. This is useful because there might be a number of binding errors and the ErrorSummary will give us the whole list.

At this point, I’m just repeat what’s stated in Caliburn’s documentation. NH Prof was the first project where we’ve actually used the Testability features of Caliburn. Let’s check out a real live test from it:

[TestFixture]
public class MessageBoxViewTextFixture : ViewTestFixtureBase
{
    private readonly ValidationResult<MessagePresenter> bindings;

    public MessageBoxViewTextFixture()
    {
        bindings = Validator.For<MessageBoxView, MessagePresenter>()
            .Validate();
    }

    [Test]
    public void BindingsDoNotHaveErrors()
    {
        Assert.That(bindings.HasErrors, Is.False, bindings.ErrorSummary);
    }

    [Test]
    public void MessageIsBound()
    {
        Assert.That(bindings.WasBoundTo(x => x.Message));
    }
}

This test is for the view that displays a simple popup message. We have a simple presenter that backs the view and it has a message to display in its property Message. It’s tested independent of the view. (This is nice because we have a case in NH Prof where a single presenter might be bound to multiple views.)

The ViewTestFixtureBase is identical to TestBase from the example above. Since it’s expensive to have Caliburn instantiate and crawl the UI validating the bindings, we only want to do this once. (I’m not really sure why I used the constructor, instead of [TestFixtureSetUp], but I did.)

The first test covers 90% of what you typically need, catching spelling errors, etc. The second test however explicitly checks to see if we are bound to the Message property on the presenter. This is useful because that’s the core reason for this view. There may be other properties bound, but this is the one we definitely care about. (I think this affords liberty to designers while ensuring that a view delivers the business value that was intended.)

Now, let’s pretend that I have a bad binding in my markup. Here’s the core snippet for the view used in the test above, MessageBoxView:

<Grid MaxWidth="260">
    <StackPanel>
        <TextBlock Foreground="{StaticResource Text}" 
                   FontSize="14"
                   TextWrapping="Wrap"
                   Text="{Binding Messyage}" />
        <Button Content="OK"
                Margin="4 8 4 4"
                HorizontalAlignment="Center"
                IsCancel="True" />
    </StackPanel>    
</Grid>

Oops, I misspelled Message in the binding! When I execute my tests, they both fail. The first because there is a binding error and the second because it can’t find Message. Here’s the actual exception from the first test:

NUnit.Framework.AssertionException: [MessageBoxView.Grid.StackPanel.TextBlock] The property 'Messyage' was not found on 'MessagePresenter'.
Expected: False
But was: True

Notice that it actually gives you the path to the offending binding: MessageBoxView.Grid.StackPanel.TextBlock. Now that’s just cool! Thanks Rob!

I can’t explain how much pain it saves to be able to do this. If you are doing TDD with WPF, you really need to check this out.

I’ll post over the weekend some tests that are a bit more BDD in their styles.