MVVM - SeeSharp

WPF Application with Caliburn - Part Three

HEskandari — Tue, 22 Jun 2010 00:00:00 GMT

This is the 3rd part of the serie where in previous post we saw how to develop WPF applications using Caliburn Framework. In this post, we'll see some more advanced usage where our shell instead of being just limited to displaying single view at a time, can have multiple ones in a Tabbed user interface.

Note: I'm still using v1.1 of Caliburn framework. In this version naming are more toward MVP pattern but the framework can be used to implement WPF and Silverlight applications in both MVP and MVVM patterns. Next version of Caliburn will have better namings that are not design pattern specific. If you are using later versions of the framework, classes may have quite different namings.

Basic Shell
To recap, creating a basic shell in WPF using MVVM pattern that benefits Caliburn framework was fairly simple. You needed to create a View which is basically a UserControl for the shell and place a ContentControl in it which will be the placeholder for other views to open in. For the ViewModel part, there was a couple of base class to choose from but so far we've used PresenterManager which can host and display single "Presenter".

<UserControl x:Class="iSales.Views.ShellView">
    <DockPanel LastChildFill="True">
	
        <ToolBar DockPanel.Dock="Top">
            <Button cal:Message.Attach="[Event Click] = [Action ShowCustomers]" Content="Customers" />
            <Button cal:Message.Attach="[Event Click] = [Action ShowOrders]" Content="Orders" />
        </ToolBar>

        <ContentControl cal:View.Model="{Binding CurrentPresenter}" />
		
    </DockPanel>
</UserControl>

Tabbed Interface
Let's create a more sophesticate UI that allows us host multiple views at the same time. You may know that it is originally not possible to do MDI interface in WPF (there were community implementations though) however it would be possible to achieve similar results using a TabControl.

To convert our single-view to a tabbed-view there are two things to do. First we should change the base class of our ShellViewModel to "MultiPresenterManager" instead of "PresenterManager", then we need to change the UI part (ShellView) to host a collection of "IPresenters" in a tabbed interface. To change the UI, remove the ContentControl and add a TabControl with its ItemsSource bound to "Presenters" property and SelectedItem bound to "CurrentPresenter" property. So far it all comes down to one line of code change on the UI:

<TabControl ItemsSource="{Binding Presenters}" SelectedItem="{Binding Path=CurrentPresenter}" />

As you can see the picture above, it is not what we expected, or is it? You may have guessed what is missing. We need to provide two things to the TabControl: A template for Header part where tab item's header will be displayed, and another template for the content part of the tab item where our view will be displayed. For the header part, Caliburn already has a property named "DisplayName" which is designed to do just that.

<TabControl ItemsSource="{Binding Presenters}" 
            SelectedItem="{Binding Path=CurrentPresenter}">
	
    <TabControl.ItemTemplate>
        <DataTemplate>
            <ContentControl Content="{Binding DisplayName}"/>
        </DataTemplate>
    </TabControl.ItemTemplate>
	
    <TabControl.ContentTemplate>
        <DataTemplate>
            <ContentControl cal:View.Model="{Binding}" />
        </DataTemplate>
    </TabControl.ContentTemplate>
	
</TabControl>

The result is a more elegant user interface and our tab control displays and hosts our presenters correctly.

Closing Tabs
If you have noticed, one piece of the puzzle is still missing. How do we close a view once we have opened it? Let's retemplate our ItemTemplate in the TabControl and add button with a glyph that will close the Presenter once clicked. First let's add a method in our ShellView to close the passed presenter.

using Caliburn.PresentationFramework.ApplicationModel;

public class ShellViewModel : MultiPresenterManager, IShellViewModel
{
    public void ShutdownPresenter(IPresenter presenter)
    {
        this.Shutdown(presenter);
    }
}

Notice the "Using" keyword. There is an extension method for shutdown so we're importing the extension method with using keyword and just pass the presenter to be shutdown. Here's our complete new template:

<DataTemplate>
    <ContentControl>
        <DockPanel>
            <Button Style="{StaticResource {x:Static ToolBar.ButtonStyleKey}}" 
                Visibility="{Binding CanShutdown, Mode=TwoWay, Converter={StaticResource VisibilityConverter}}"
                cal:Message.Attach="[Event Click] = [Action ShutdownPresenter($datacontext)]"
		DockPanel.Dock="Right">
                    <Path Stretch="Fill" StrokeThickness="0.5" 
                          Stroke="#FF333333" Fill="#FF969696" 
                          Data="F1 M 2.28484e-007,1.33331L 1.33333,0L 4.00001,2.66669L 6.66667,6.10352e-005L 8,1.33331L 5.33334,4L 8,6.66669L 6.66667,8L 4,5.33331L 1.33333,8L 1.086e-007,6.66669L 2.66667,4L 2.28484e-007,1.33331 Z " 
                          HorizontalAlignment="Stretch" 
                          VerticalAlignment="Stretch"/>
            </Button>
            <TextBlock Text="{Binding DisplayName}" />
        </DockPanel>
    </ContentControl>
</DataTemplate>

Did you see the part where we are attaching a Message to the Click event of the button? In Caliburn you can attach a method of your ViewModel to the UI element. What's cool about it (well there are many cool things about it) is that you can even pass the DataContext around and Caliburn will do the necessary casting for you so in our case, DataContext of the Button will be cast as an IPresenter and will be injected to the method when user clicks on the close button.

One thing that you may experience when closing the Shell view (Main Window), is that by doing so, shell will give all the open presenters a chance to clean up and close gracefully. In case a presenter is not in a closeable state, the close operation on the entire application will be cancelled.

That' all there is to it. Now we have an elegant tabbed UI where user can open and close each tab separately. You can grab the source code of this part from here.

Best implementation of INotifyPropertyChange ever

HEskandari — Mon, 26 Apr 2010 00:00:00 GMT

Back in May 2008, I found a way to use Linq expression to fire notification change, and just after that on September 2008, changing the first implementation to benefit extension methods, things looked a lot easier and more C# 3.0 style. But now to think of it, the best implementation of INotifyPropertyChange would be not to implement it at all! Is this possible?

If you're a WPF or Silverlight programmer, you probably aready know that to make data binding work on simple POCO objects, you need to implement INotifyPropertyChange interface on your POCO class. This is a trivial interface which has a public event. When property value changes, it is your job to notify interested parties about this change and WPF / SL engine is one of the interested parties and will update the UIElement that is bound to that property automatically. How to do that is actually easy too, but a lot of repetitive boiler-plate code should be written:

public class Customer
{
}

public class CustomerViewModel : INotifyPropertyChanged
{
    private Customer _currentCustomer;
    public virtual Customer CurrentCustomer
    {
        get { return _currentCustomer; }
        set
        {
            _currentCustomer = value;
            RaisePropertyChanged("CurrentCustomer");
        }
    }

    private void RaisePropertyChanged(string propertyName)
    {
        var handler = PropertyChanged;
        if(handler != null)
        {
            handler(this, new PropertyChangedEventArgs(propertyName));
        }
    }
    
    public event PropertyChangedEventHandler PropertyChanged;
}

Yuck! Even using LINQ and Extension methods just changes the untyped property name to its typed equivalent but the amount of code written hardly changes.

Let's see how we can just create an automatic property and make it notify the property change event, without doing all these stuff. In short, let us see how to make this red test turn green:

[TestFixture]
public class AutomaticNotificationFixture
{
    [Test]
    public void Notification_Change_Is_Added_Automatically()
    {
        var vm = new CustomerViewModel();

        var notification = vm as INotifyPropertyChanged;

        Assert.That(notification, Is.Not.Null);
    }

    [Test]
    public void Can_Notify_Automatically()
    {
        var vm = new CustomerViewModel();
        string changedProperty = null;

        ((INotifyPropertyChanged) vm).PropertyChanged += (s, e) => changedProperty = e.PropertyName;
        vm.CurrentCustomer = new Customer();

        Assert.That(changedProperty, Is.Not.Null);
        Assert.That(changedProperty, Is.EqualTo("CurrentCustomer"));
    }

    public class Customer
    {
    }

    public class CustomerViewModel
    {
        public virtual Customer CurrentCustomer
        {
            get; set;
        }
    }
}

Not possible at first look, eh? If you're familiar with DynamicProxy tools, you can well see the perfect usage here. In short, using a dynamic proxy library, we could implement an interface on our type at runtime, so we could inject the INotifyPropertyChange behavior into our ViewModel here. This is a pretty powerful toy which allows you any kind of behavior into your objects with minimal effort.

Let's create a ViewModelFactory for ourselves that just does that:

public class ViewModelFactory
{
    private static readonly ProxyGenerator ProxyGenerator = new ProxyGenerator();

    public static T Create<T>()
    {
        return (T)Create(typeof(T));
    }

    public static object Create(Type type)
    {
        return ProxyGenerator.CreateClassProxy(type, new[]
        {
            typeof(INotifyPropertyChanged), 
        }, 
        new NotifyPropertyChangedInterceptor());
    }
}

We need to create an Interceptor for our behavior too. Interceptor as the name implies, will be called on our class at runtime and gives us a chance to run a piece of code before and / or after a call is made on our object.

public class NotifyPropertyChangedInterceptor : IInterceptor
{
    private PropertyChangedEventHandler _subscribers = delegate { };

    public void Intercept(IInvocation invocation)
    {
        if (invocation.Method.DeclaringType == typeof(INotifyPropertyChanged))
        {
            HandleSubscription(invocation);
            return;
        }

        invocation.Proceed();

        if (invocation.Method.Name.StartsWith("set_"))
        {
            FireNotificationChanged(invocation);
        }
    }

    private void HandleSubscription(IInvocation invocation)
    {
        var handler = (PropertyChangedEventHandler)invocation.Arguments[0];

        if (invocation.Method.Name.StartsWith("add_"))
        {
            _subscribers += handler;
        }
        else
        {
            _subscribers -= handler;
        }
    }

    private void FireNotificationChanged(IInvocation invocation)
    {
        var propertyName = invocation.Method.Name.Substring(4);
        _subscribers(invocation.InvocationTarget, new PropertyChangedEventArgs(propertyName));
    }
}

As you can see, the IInvocation interface contains the method that is being executed so we can see if it is an event subscription, a property getter/setter or a method call and act respectivly.

Now we only need to create our ViewModel classes via our factory so let's refactor our test code to this and see the tests pass.

var vm = ViewModelFactory.Create<CustomerViewModel>();

How does this fit to your application? It goes without saying that you can not create instances of your ViewModels and need to get new instances via this factory, but if you're using a presentation framework like Caluburn, or using dependency injection containers like Windsor to resolve your VMs, you'll feel right at home.

So, what's the catch? There's always a catch, you might ask? There's no catch seriously. Well, now that you insist, there is just one point. To be able to do so, you need to make your properties "virtual" as the sample above. I don't consider this a "catch" since making your public API virtual is considered a good thing for many reasons and you probably do that anyway.

WPF Application with Caliburn - Part Two

HEskandari — Fri, 15 Jan 2010 00:00:00 GMT

In this part of the tutorial, we'll enhance our shell view to display other presenters and add Save and Print support for presenters supporting it. You can use generalize this example and learn how to implement generic features in your shell.

Caliburn has several existing classes that can be used as a base class for our presenters. Let's explain some of them and see where do they fit:

Presenter
This class implements IPresenter interface and provides life time methods such as Initialize, Shutdown, Active and Deactive. You can use this class for other views that are going to be displayed in the Shell View.

Presenter Manager
Using a presenter manager, as the name implies, you can host and display a single instance of a Presenter. It only allows displaying of one Presenter only so you have only one view displayed to the user when using it.

MultiPresenterManager
Same as PresenterManager but can host multiple Presenters at the same time, but only one of them is Active at a time.

When we display a Presenter, the PresenterManager will call the lifetime methods on the Presenter instance. The following diagram shows this flow:

For now, it is obvious that we need to change the base class of our ShellViewModel to PresenterManager (too keep it simple for the time being), but how should we change the xaml code to host the views (other Presenters)? Your first guess would be to bind CurrentPresenter property of the PresenterManager to a ContentControl in the Shell.xaml, but you don't need to do that as Caliburn will do the plumbing for us, just add a ContentControl to the Shell view where you want the views to be displayed and name it as "CurrentPresenter".

To make Caliburn bind Views to the content control, you need to enable additional Conventions that are not enabled by default. Placing the following snippet in Caliburn configuration will do the trick:

var binder = (DefaultBinder)Container.GetInstance<IBinder>();
binder.EnableBindingConventions();

The bare bone of the shell view that displays a single presenter is this:

<Window x:Class="PayRoll.Views.ShellView"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Width="640" Height="400">
    <DockPanel LastChildFill="True">

        <ScrollViewer>
            <ContentControl x:Name="CurrentPresenter" />
        </ScrollViewer>

    </DockPanel>
</Window>

Adding Custom Controls
Now to handle user interaction with the shell and the open presenter, we need some kind of a Toolbar / Menu control. WPF comes with a very basic menu and toolbar control, but to show how to use custom controls and see how Caliburn facilitates this, let's use DevExpress BarManager control in this example.

DevExpress, among other nice things, provides presentation layer controls for WPF such as Editors, Bars (MenuBar, ToolBar and soon Ribbon), Grid and Printing. One other thing they've also done is that they also have skinned native WPF controls so if used together with DevExpress controls, you'll have a seemless look and feel.

To add the BarManager control to our ShellView, you need to download DevExpress WPF controls (trial version here) and install it. The add the necessary reference to devexpress WPF assemblies and import the xml namespaces. Here's the snippet that creates the BarButtonItems which is equivalent of a ToolbarItem. (Get the accompanied zip for complete source code):

<dxb:BarManager.Items>
	<!--General Actions-->
	<dxb:BarButtonItem Name="bSave"  CategoryName="File" Content="Save" Glyph="/Images/Save.png"  KeyGesture="Ctrl+S" />
	<dxb:BarButtonItem Name="bPrint" CategoryName="File" Content="Print" Glyph="/Images/Print.png" KeyGesture="Ctrl+P" />
	<dxb:BarButtonItem Name="bExit"  CategoryName="File" Content="Exit" Glyph="/Images/Exit.png" KeyGesture="Ctrl+X" />
	
	<!--Status Bar-->
	<dxb:BarStaticItem Name="bStatus" CategoryName="Status" MinWidth="300" Content="Read" AutoSizeMode="Fill"/>
</dxb:BarManager.Items>

Same as Button object, BarButtonItems provide a Command property which you can bind to an ICommand instance on your ViewModel, but this is rather limited, don't you think? What if you want to bind another event (other then Click) to your ViewModel?

Caliburn provides Actions and Messages with which you can bind a regular Event on your View and Controls to a method on your ViewModel, without using ICommand. You can even run the event handler (on your VM) asynchronously! There are a few ways to do this but the best way, in my opinion, is to this format:

cal:Message.Attach="[Event EventNameOnControl] = [Action ActionNameOnViewModel()]"

Note that you can actually bind two actions to one event, just like you can have two methods listening to a regular event. Let's change the snippet above and add the messaging support:

<dxb:BarButtonItem Name="bSave" cal:Message.Attach="[Event ItemClick] = [Action SavePresenter()]"/>
	<dxb:BarButtonItem Name="bPrint" cal:Message.Attach="[Event ItemClick] = [Action PrintPresenter()]"/>
	<dxb:BarButtonItem Name="bExit" cal:Message.Attach="[Event ItemClick] = [Action Exit()]" />

Note: Unlike a regular Button, BarButtonItem has no "Click" event and provides an "ItemClick" event instead. Clearly, we need the specified methods on our ViewModel, so let's add them too:

public class ShellViewModel : PresenterManager, IShellViewModel
{
    public virtual void SavePresenter()
    {
    }

    public virtual void PrintPresenter()
    {
    }

    public virtual void Exit()
    {
    }
}

At this point, you can run the shell and click the tool bar items, which will call the specified method on the view model. Now the question is, what if a presenter is not in a suitable state to be saved (dirty checking, already saved, etc.). What if a presenter does not even support printing? How can we disable the BarButtonItem responsible for an action, if the presenter does not support it?

With Conventions already enabled, you can have additional "Can*" methods acting as a Filter for your actions. These filters will be checked on runtime for returning false value indicating the action can not be performed, or true value for allowed actions. Caliburn will try to disable the piece of UI through an "IAvailabilityEffect" interface. Let's see this in more dept.

Working with Actions
As mentioned, Caliburn checks for availability of an action automagically if it finds a pairing "Can*" filter method on the presenter. So let's add those and see how it works:

public virtual bool CanExit()
{
    return base.CanShutdown();
}

public virtual bool CanPrintPresenter()
{
    var presenter = CurrentPresenter as IPrintablePresenter;
    return presenter != null &&
           presenter.CanPrint;
}

public virtual bool CanSavePresenter()
{
    var presenter = CurrentPresenter as ISaveablePresenter;
    return presenter != null &&
           presenter.CanSave;
}

When you run the application and set a break point on CanSave and Save methods, you'll notice two things:

A. While CanPrint method returns False value, UI element (BarButtonItem) is not disabled!

B. By clicking the BarButtonItem, the Save method will not be called.

So there seems to be a problem...Why isn't BarButtonItem disabled? Wasn't Caliburn supposed to do that for us? Well...The default "Disable" effect, only works for UIElements, but BarButtonItem is actually a FrameworkContentElement. Those are two different beasts and Caliburn can not handle our UI control. The solution is easy though. You can create your own IAvailabilityEffect that works with FrameworkContentElements.

public class DisableMenuEffect : IAvailabilityEffect
{
    public void ApplyTo(DependencyObject target, bool isAvailable)
    {
        var element = target as FrameworkContentElement;
        if(element == null)
            return;

        element.IsEnabled = isAvailable;
    }
}

...and set it along with the action on the View:

<dxb:BarButtonItem cal:Message.Attach="[Event ItemClick] = [Action SavePresenter()]" cal:Message.AvailabilityEffect="DisableMenuEffect" />
    <dxb:BarButtonItem cal:Message.Attach="[Event ItemClick] = [Action PrintPresenter()]" cal:Message.AvailabilityEffect="DisableMenuEffect" />
    <dxb:BarButtonItem cal:Message.Attach="[Event ItemClick] = [Action Exit()]" cal:Message.AvailabilityEffect="DisableMenuEffect" />

There's one last trick to make this work. Caliburn has no way to convert the specified string to an IAvailabilityEffect instance! The existing ValueCovertor, asks our Container for any object named "DisableMenuEffect". The final piece of code would be to register all instances of IAvailabilityEffects you might want to use on the container:

_container.Register(Component.For<DisableMenuEffect>()
                             .Named("DisableMenuEffect")
                             .LifeStyle.Singleton);

When running the application, and there's no open view, the toolbar items are disabled.

To show how it works, let's add a new View and ViewModel to our application, and also add a button to the shell that allows us to open this view. As mentioned before, to do this, you need to create a UserControl for you View and a class deriving from Presenter base class for your ViewModel.

public class PersonViewModel : Presenter
{
    private Person _person;
    private ObservableCollection<Person> _personnelList;
    private ObservableCollection<Job> _jobs;
    private readonly IPersonDataService _service;

    public PersonViewModel(IPersonDataService service)
    {
        _service = service;
    }

    public override void Initialize()
    {
        _jobs = new ObservableCollection<Job>(_service.GetJobs());
        _personnelList = new ObservableCollection<Person>(_service.GetPersonnel());
    }

    public Person CurrentPerson
    {
        get { return _person; }
        set
        {
            _person = value;
            base.NotifyOfPropertyChange("CurrentPerson");
        }
    }

    public ObservableCollection<Person> Personnel
    {
        get { return _personnelList; }
    }

    public ObservableCollection<Job> Jobs
    {
        get { return _jobs; }
    }
}

Now create a UserControl for PersonView using DevExpress editors looking like this:

To support saving, let's add ISaveablePresenter interface to our ViewModel and check if DateOfBirth property of the current person is valid before saving:

public bool CanSave
{
    get 
    {
        return CurrentPerson != null &&
               CurrentPerson.DateOfBirth.Year > 1900;
    }
}

public void Save()
{
    MessageBox.Show("Saved");
}

You can observe that CanSave property will never get executed! The reason is that when application starts, Caliburn checks if any of the Action methods are available by checking their respective Filters (here CanSavePresenter and CanPrintPresenter), but it never checks them again. In other words, by default action filters (Can* methods) are only called once. How can we change this behavior?

There's an attribute called "AutoCheckAvailability" that you can place on your action methods. This will tell WPF Command Manager to look out for availability of the bound action. Doing this will call the action filters periodically, so make sure if you really need it before actually using it. So apply this to our ViewModel, let's get back to our ShellViewModel class and place the attribute on our actions:

[AutoCheckAvailability]
public virtual void SavePresenter()
{
    var presenter = (ISaveablePresenter)CurrentPresenter;
    presenter.Save();
}

[AutoCheckAvailability]
public virtual void PrintPresenter()
{
    var presenter = (IPrintablePresenter)CurrentPresenter;
    presenter.Print();
}

Note: You need to place this on your actions, not on filters.

...et voila!

Our shell now can host other views and has generic actions that is automagically enabled / disabled for views supporting it.

In the next post, I'll show you how to change our existing shell to display a Tabbed interface and display multiple views at the same time. The attached zip file contains the complete source code.

WPF Application with Caliburn - Part One

HEskandari — Wed, 30 Dec 2009 00:00:00 GMT

Back in May 2008, I did two posts on how to implement a composite application using Caliburn framework. By that time, Caliburn was still in pre-alpha stage. With lots of the changes along the way to reach Release Candidate, those content are not valid anymore, so I thought a new post to show how you can use Caliburn to build a WPF application is in order.

In fact, a while ago I started porting my old .NET 1.1 pay roll application to WPF and .NET 3.5 so I naturally chose to use Caliburn and it did facilitate things a lot, but to keep things simple, I'm not going to discuss my own application here. I'll show how you how can create your own application using Caliburn framework and how it will help you out.

Framework Setup

First thing you need to do, is to setup a new WPF application. Let's call it PayRoll application. After doing so, add reference to Caliburn and Castle assemblies. Caliburn honors the Dependency-Injection principle by depending only on abstractions. The idea is to allow you to easily plug in your own implementation of that abstraction and customize how Caliburn components work. To do so, Caliburn uses an IoC Container to lookup the services it requires.

If you're new to Dependency Injection stuff, don't worry, there is a built-in SimpleContainer which will do the job for you but I'll be using Castle container (Windsor) here. If you're using other IoC containers such as AutoFac, Ninject, StructureMap, Spring or even MEF (not technically an IoC container), Caliburn comes with existing adapters for those too, so no worries. To lookup instances of the services it needs, Caliburn uses the Common ServiceLocator and Service Locator design pattern. This allows looking up for services from various IoC containers, without actually depending on those containers.

Now to initialize Caliburn framework at startup there are various ways, but the easiest would be to create a CaliburnApplication. We already have an application object (App.xaml and App.xaml.cs) so we only need to change them to derive from CaliburnApplication class. To do so, open the App.xaml file first, and include the Caliburn namespace and change the type to Caliburn application. Also, we don't want to specify any StartupUri, so get rid of that too. The result would be this:

<cal:CaliburnApplication x:Class="PayRoll.App"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:cal="http://www.caliburnproject.org">
    <Application.Resources>
         
    </Application.Resources>
</cal:CaliburnApplication>

With this, the project won't compile! Because we've specified different base classes in our Xaml and Code Behind. Since the base class in code behind is inferred, open the code behind and remove the base class. The code would look like this:

namespace PayRoll
{
    /// <summary>
    /// Interaction logic for App.xaml
    /// </summary>
    public partial class App
    {
    }
}

So far so good. Now, If you look at the Caliburn Application class, there are interesting things that we can do. The obvious one is a method called CreateContainer. The default implementation, as said before, will create a SimpleContainer but we're going to use our own container, so let's do so:

    protected override IServiceLocator CreateContainer()
    {
        _container = new WindsorContainer();
        return new WindsorAdapter(_container);
    }

Next step would be specifying a RootViewModel (also called ShellViewModel) that will act as ViewModel for our MainWindow. Notice that we have nothing to do with the actual View (UI) that will be displayed, we just specify the ViewModel for it:

    protected override object CreateRootModel()
    {
        return _container.Resolve<IShellViewModel>();
    }

At this point, we need to create a ViewModel and a View for our Shell and register the VM in the container. Create two folders in your solution one named Views and the other ViewModels. Create an interface in ViewModels folder named IShellViewModel and create a class implementing this yet empty interface, named ShellViewModel. So now we need to register these (along with other services, view models, etc.) in the container:

    public App()
    {
        RegisterComponents();
    }

    private void RegisterComponents()
    {
        _container.Register(Component.For<IShellViewModel>()
                                     .ImplementedBy<ShellViewModel>()
                                     .LifeStyle.Singleton);
    }

Notice that lifestyle of ShellViewModel is set to singleton. This is logical because there's always one instance of the ShellView running. We'll see how this allow us interact from other ViewModels with Shell VM.

Marrying the View and ViewModel

Now, let's run the application and see what happens. When we run the application, Caliburn throws an exception complaining that a View can not be created for the ShellViewModel. Since we didn't specify any information about our Views, you might say: How is Caliburn supposed to create a View for my ViewModel anyway? Well, Caliburn tries many things before giving up and throwing an exception:

First, if your ViewModel implements the IMetadataContainer interface, the GetMetadata method is called on your VM, asking for a view. Since this not a good option for us, let's skip it.
Second, if the ViewModel is decorated with a ViewAttribute, the specified view will be created. This is relatively easy, but it clutters your ViewModel with an attribute and I don't like it.
Third, specified assemblies will be searched to find the matching view according to a specified naming convention. This sound interesting, let's use this method.
Fourth, if you don't like any of these behaviors, you can plug in your own IViewStrategy implementation.

If you remember, we've created an empty Views folder. If you create a UserControl named ShellView (mind the naming), Caliburn will automagically pick it up as the View for our ShellViewModel. How is this done, you may ask? According to pre-defined naming rules, Caliburn will look in folders named Presenter, Model, ViewModel and PresentationModel to create a ViewModel instance, and to create a View instance, it will look for it in the Views folder. An example might clear it up a little bit. Supposing you have an IShellPresenter, the implementation would be named ShellPresenter in the folder named Presenters. You should name the view for this presenter ShellView and place it in Views folder. The ViewModel names refers to different implementation of Presentation Model design pattern, but those terms are used interchangeably in Caliburn.

So, we're going to use the naming convention (fourth method). Let's create an empty UserControl named ShellView and put it in Views folder:

<UserControl x:Class="PayRoll.Views.ShellView"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    
</UserControl>

You can run the application now and it works. Caliburn has created a View (UI) and a POCO class as ViewModel and set the DataContext property of the View to the instance of the ViewModel. If you've noticed, we've set a UserControl as our root View. While you can create a Window object as your root View, if you create a UserControl (or anything other than a Window), Caliburn will create a MainWindow for you and place the View object as its content. This behavior is for Caliburn v1.1 so if you're using older version 1.0 you can either upgrade or use a Window as your root view.

Binding

To check if View and ViewModel are really bound together, let's create a commmand on the ViewModel and invoke it from the View. When invoked, it will change a Message property on the ViewModel. So first, open the IShellViewModel interface and add the ICommand and Message properties to the interface definition:

    public interface IShellViewModel
    {
        /// <summary>
        /// A command that says hello when invoked.
        /// </summary>
        ICommand SayHelloCommand { get; }

        /// <summary>
        /// Message
        /// </summary>
        string Message { get; set; }
    }

...and implement the command property on your ShellViewModel class. To facilitate command handling, we'll use a DelegateCommand class (originally RelayCommand) introduced by Josh Smith. Then instead of just displaying a MessageBox, let's Create a TextBlock and bind it to the Message property on our ViewModel. When binding some element to a property on the ViewModel, we need to implement INotifyPropertyChanged interface on the ViewModel. Fortunately, there's a base class in Caliburn which does exactly that:

    public class ShellViewModel : PropertyChangedBase, IShellViewModel
    {
        private ICommand _sayHelloCommand;
        private string _message;

        public virtual ICommand SayHelloCommand
        {
            get
            {
                if (_sayHelloCommand == null)
                    _sayHelloCommand = new DelegateCommand(SayHello);

                return _sayHelloCommand;
            }
        }

        public virtual string Message
        {
            get { return _message; }
            set
            {
                _message = value;
                NotifyOfPropertyChange("Message");
            }
        }

        private void SayHello()
        {
            Message = "Greetings from Caliburn!";
        }
    }

...Finally, let's place a Button and a TextBlock on the View and bind those to our ViewModel:

<Window x:Class="PayRoll.Views.ShellView"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Width="320" Height="200" >
    <StackPanel>
        
        <Button Command="{Binding Path=SayHelloCommand}" Content="Say Hello"  />
        
        <TextBlock Text="{Binding Path=Message}" FontSize="16" FontWeight="Bold" />
        
    </StackPanel>
</Window>

In next post, I'll show you how to add DevExpress components to the pot and how to create a re-usable shell and along the way. We'll see how to host other ViewModels in our ShellView and how to manage them. You can get the source code of this part from here.

Caliburn = Less Code?

HEskandari — Wed, 02 Sep 2009 11:59:00 GMT

Caliburn is an application framework for WPF / Silverlight. If you're developing applications for these platforms, there are many reasons why you definitely need to be using this framework, but today, I noticed how using this framework resulted writing less code while doing more. Let's see how writing a small WPF application using MVVM pattern is different when using Caliburn. Note: There are many other ways to skin a cat. This is how I do things, there may be other, better ways to do the same thing.

Application Startup
When creating an application using MVVM and ViewModel First development, you'd create the root View and VM, bind them through DataContext and show the main window of the application.

///
/// Interaction logic for App.xaml
///
public partial class App : Application
{
    protected override void OnStartup(StartupEventArgs e)
    {
        base.OnStartup(e);
        
        var container = new WindsorContainer();
        var rootView = new RootView();
        var rootModel = new RootViewModel();
        
        rootView.DataContext = rootModel;
        this.MainWindow = rootView;
        this.MainWindow.Show();
    }
}

With caliburn, all you need to do is to create the root VM. There's no trace of any View creation and binding the DataContext to VM. All this is done automatically by Caliburn. To do this, use CaliburnApplication as your base application class which will configure Caliburn framework upon startup. There are other ways to do the configuration but let's stick to this simple configuration scenario that installs default implementations of Calburn Components.

///
/// Interaction logic for App.xaml
///
public partial class App : CaliburnApplication
{
    protected override IServiceLocator CreateContainer()
    {
        var container = new WindsorContainer();
        var adapter = new WindsorAdapter(container);
        
        return adapter;
    }
    
    protected override object CreateRootModel()
    {
        return new RootViewModel();
    }
}

One thing a little different is that Caliburn uses IServiceLocator insterface (from Common Service Locator) and has no direct dependency on a vendor specific IoC Container, which is a good thing. This means, you can choose various IoC containers and adapters for major IoC containers like Windsor, Ninject, Autofac, etc. are already included in Caliburn bits. If you're not a fan of IoC containers and won't be using one in your application (now, come on!), Caliburn uses a lightweight built-in container, in case you don't specify any other.

Actions and Commands
Should you bind an action to a ICommand instance on the VM, in pure MVVM application you would bind the Command property to an ICommand instance on the VM. You can specify the condition on which the command will be executable and you'll also implement the action execute by the command.

<Button Command="{Binding ExitCommand}" Content="Exit Application">

public class RootViewModel : BaseViewModel
{
    private ICommand _exitCommand;
    public ICommand ExitCommand
    {
        get
        {
            if (_exitCommand == null)
                _exitCommand = new RelayCommand(this.Exit, this.CanExit);
            
            return _exitCommand;
        }
    }
    
    public bool CanExit()
    {
        return true;
    }
    
    public void Exit()
    {
        Application.Current.Shutdown();
    }
}

Notice there are other hidden code here too. You'll need to create a new Command, or use RelayCommand (kudos to Josh) and you probably need a common layer supertype that implements INotifyPropertyChanged interface. Using Caliburn you'd bind the action directly to the VM and there's no dependency to ICommand instances. The good thing is, you're not limited to Command property anymore and you can bind various other events such as Click, MouseOver, etc. to actions on your VM.

<Button cal:Message.Attach="[Event Click] = [Action Exit]" Content="Exit Application">

public class RootViewModel : Presenter
{
    public bool CanExit()
    {
        return true;
    }
    
    public void Exit()
    {
        Application.Current.Shutdown();
    }
}

There are lots of existing boilerplate functionalities already available in Caliburn, so you can drop BaseViewModel and use Presenter class (IPresenter implementation).

Displaying Views
To display other views in the RootView (e.g. Shell), we'd constructed a new VM and set it to a Content property of a ContentControl. This will actually pick up the view specified in the DataTemplate from Application Resources, and display it on the UI. You have to maintain a mapping between your Views and your VMs in a resource dictionary and as your application grows this gets harder to maintain.

<Application.Resources>
    <DataTemplate DataType="{x:Type vm:CustomerViewModel}">
        <view:CustomerView />
    </DataTemplate>
</Application.Resources>

<ContentControl Content="{Binding Path=CurrentView}"/>

public class RootViewModel : BaseViewModel
{
    public void ShowCustomer()
    {
        CurrentView = IoC.Resolve<Customerviewmodel>();
    }
    
    private BaseViewModel _currentView;
    public BaseViewModel CurrentView
    {
        get { return _currentView; }
        set
        {
            _currentView = value;
            RaisePropertyChanged("CurrentView");
        }
    }
}

Let's see how we can do this using Caliburn. First off, we do not need to maintain any ViewModel mapping if we name our Views and ViewModels according to the Caliburn Conventions that is, your view names should ending in View, presenters / VMs ending in ViewModelor Presenter and each should be in a separate namespace, namingly Views and ViewModels or Presenters. This is just by convention and you can always override if you need to. Caliburn will automatically create the view for you, set the CurrentPresenter property on the main window (i.e. IPresenterHost) and do any required bindings. Did I mention you don't need the whole mapping of View <-> DataTemplate in your Application / Form resource?

<ContentControl x:Name="CurrentPresenter" >

[Singleton("RootViewModel")]
public class RootViewModel : PresenterManager
{
    public void ShowCustomer()
    {
        var presenter = ServiceLocator.Current.GetInstance<Customerviewmodel>();
        this.Open(presenter);
    }
}

Conclusion
What's the catch? How does Caliburn do this? Caliburn uses Convention over Configuration pattern, so if you do things according to the convention you'll end up saving a lot of code. There's always the possibility to change the default behavior too. By complying to these conventions, clearly you'll end up writing less code, but more importantly the code you do write is cleaner, more robust and probably with better testabilty. With the help of Binding Tests utilities existing in Caliburn, you can test your bindings the easy way, which is some thought for later posts.

MVVM Validation With NHibernate Validator

HEskandari — Sat, 16 May 2009 13:19:00 GMT

Simplest way to do Validation in WPF is usually implementing IDataErrorInfo interface, and do the validation in the indexer's getter. It turns out to be ugly and gets out of hand when your model / viewmodel gets a little larger. Implementing the IDataErrorInfo is as simple as this:

public string this[string propertyName]
{
  get
  {
      //Validate property that is being set,
      //and return an error message if there's
      //any error.

      return null;
  }
}

public string Error
{
  get { return string.Empty; }
}

I intend to use NHibernate Validator attributes to add non-intrusive validation to my ViewModel classes. So you'd just decorate properties of your ViewModel and let WPF and NHibernate Validator do the rest for you. Before we do that, let's create a more elegant way to show the errors by restyling the TextBox control and add an Error Icon and tooltip to it in case of an error existing:

<Style TargetType="{x:Type TextBox}">
   <Setter Property="Validation.ErrorTemplate">
       <Setter.Value>
           <ControlTemplate>
               <DockPanel LastChildFill="True">
                   <Image x:Name="ErrorIcon" Source="Images/FieldError.png" DockPanel.Dock="Right" Width="16" Height="16" Margin="4,0,0,0" />
                   <Border BorderBrush="Red" BorderThickness="1">
                       <AdornedElementPlaceholder />
                   </Border>
               </DockPanel>
           </ControlTemplate>
       </Setter.Value>
   </Setter>
   <Style.Triggers>
       <Trigger Property="Validation.HasError" Value="true">
           <Setter Property="ToolTip" Value="{Binding RelativeSource={RelativeSource Self}, Path=(Validation.Errors)[0].ErrorContent}"/>
       </Trigger>
   </Style.Triggers>
</Style>

Now that styles are all set, let's configure NHibenrate Validator's engine on application startup. Nothing fancy, just a straightforeward configuration. We'll use a shared validation engine:

public void RegisterValidatorEngine()
{
  var config = new NHVConfigurationBase();

  config.Properties[Environment.ApplyToDDL] = "false";
  config.Properties[Environment.AutoregisterListeners] = "true";
  config.Properties[Environment.ValidatorMode] = "UseAttribute";
  config.Properties[Environment.SharedEngineClass] = typeof(ValidatorEngine).FullName;
  config.Mappings.Add(new MappingConfiguration(DomainAssemblyName, null));

  Environment.SharedEngineProvider = new NHibernateSharedEngineProvider();
  Environment.SharedEngineProvider.GetEngine().Configure(config);

  ValidatorInitializer.Initialize(NHibernateConfig);
}

And to make things reusable, why not create a base ViewModel:

public abstract class ValidatableViewModel : IDataErrorInfo
{
  private readonly ValidatorEngine validation;

  protected ValidatableViewModel()
  {
      validation = Environment.SharedEngineProvider.GetEngine();
  }

  public string this[string propertyName]
  {
      get
      {
          var rules = GetInvalidRules(propertyName);
          if (rules != null && rules.Count > 0)
          {
              return rules[0].Message;
          }

          return null;
      }
  }

  public string Error
  {
      get { return string.Empty; }
  }

  public IList GetInvalidRules(string propertyName)
  {
      var type = this.GetType();

      return validation.ValidatePropertyValue(type, propertyName, GetPropertyValue(type, propertyName));
  }

  public IList GetAllInvalidRules()
  {
      return validation.Validate(this);
  }

  private object GetPropertyValue(Type objectType, string properyName)
  {
      return objectType.GetProperty(properyName).GetValue(this, null);
  }
}

The rest is just to inherit the ValidatableViewModel and add necessary attributes to our binded properties. A sample ViewModel containing a Save command, which is invocable only when there's no error on the model and a couple of other business properties would look like this:

public class NewAccountViewModel : ValidatableViewModel, INotifyPropertyChanged
{
  private string _firstName;
  private string _lastName;
  private string _currentBalance;

  [NotNullNotEmpty]
  public string Firstname
  {
      get { return _firstName; }
      set
      {
          _firstName = value;
          this.Notify(this.PropertyChanged, o => o.Firstname);
      }
  }

  [NotNullNotEmpty]
  public string Lastname
  {
      get { return _lastName; }
      set
      {
          _lastName = value;
          this.Notify(this.PropertyChanged, o => o.Lastname);
      }
  }

  [IsNumeric]
  [NotNullNotEmpty]
  public string CurrentBalance
  {
      get { return _currentBalance; }
      set
      {
          _currentBalance = value;
          this.Notify(this.PropertyChanged, o => o.CurrentBalance);
      }
  }

  public event PropertyChangedEventHandler PropertyChanged = delegate { };

  private ICommand _cmdSave;
  public ICommand SaveCommand
  {
      get
      {
          if (_cmdSave == null)
              _cmdSave = new RelayCommand(Save, CanSave);

          return _cmdSave;
      }
  }

  public void Save()
  {
      MessageBox.Show("Save");
  }

  public bool CanSave()
  {
      return GetAllInvalidRules().Count == 0;
  }
}

<UserControl x:Class="Jimba.UI.View.NewAccountView"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
  <StackPanel>
      <StackPanel Orientation="Horizontal">
          <Label Width="100">Firstname:</Label>
          <TextBox Text="{Binding Path=Firstname, UpdateSourceTrigger=PropertyChanged, ValidatesOnDataErrors=True}" />
      </StackPanel>

      <StackPanel Orientation="Horizontal">
          <Label Width="100">Lastname:</Label>
          <TextBox Text="{Binding Path=Lastname, UpdateSourceTrigger=PropertyChanged, ValidatesOnDataErrors=True}" />
      </StackPanel>

      <StackPanel Orientation="Horizontal">
          <Label Width="100">Current Balance:</Label>
          <TextBox Text="{Binding Path=CurrentBalance, UpdateSourceTrigger=PropertyChanged, ValidatesOnDataErrors=True}" />
      </StackPanel>
  </StackPanel>
</UserControl>