Last time I showed how I’m transfering Notifications from the ViewModel into the logical WPF tree. If you’ve not read the previous posts, please give them some minutes, because I’m not going to repeat a lot of them today. You can find them here, here and here.

As always, a quick reminder: What I’m showing is in this series is how I’ve implemented the Notification Pattern. I’m not claiming that it’s the only or the best way to do so. However, it’s the one that works very good for me.

How to get the red border effect

The red border has to be displayed when Notifications exists for a control. Technically this means
that the attached property “Notifications” (which is defined on the ValidationBehavior class I showed in the last post) is set to a non empty NotificationCollection.

We can react to this by defining a DataTrigger for this. In my own words I would describe DataTriggers as

An in XAML defined event handler with a related criteria. When the criteria is matched the DataTrigger gets executed. When it isn’t matched any more, the DataTrigger reverts the state of the element on which it’s defined to the state before it was executed.

Sounds usable for our purpose. Think about it, we only want to show the red border, when the attached property is set to a non empty collection. If the property is reset the border needs to disappear.

The only difficulty with DataTriggers we need to solve on our way is how to configure that exactly in XAML. DataTriggers can be easily set on primitives (such as string, bool, etc.) or null, but there isn’t an out of the box way for setting our criteria in XAML.

However you can use a custom Converter for converting our value to a primitive “switch”.

    [ValueConversion(typeof(NotificationCollection), typeof(bool))]
    public class ContainsNotificationConverter : IValueConverter
    {
        public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
        {
            return (value != null && value is NotificationCollection && ((NotificationCollection)value).Any());
        }

        public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
        {
            throw new NotSupportedException();
        }
    }

Using this converter we can define our DataTrigger in the Style for Controls like this:

   <Fx:ContainsNotificationConverter x:Key="notificationConverter" />

   <Style TargetType="Control">
        <Setter Property="Fx:ValidationBehavior.IsEnabled" Value="true" />
        <Style.Triggers>
            <DataTrigger
                Binding="{Binding Path=(Fx:ValidationBehavior.Notifications),
                Converter={StaticResource notificationConverter},
                RelativeSource={x:Static RelativeSource.Self}}" Value="true">
                <Setter Property="BorderBrush" Value="Red" />
                <Setter Property="BorderThickness" Value="2" />
            </DataTrigger>
        </Style.Triggers>
    </Style>

How to display Notifications in a Tooltip

Solving the Tooltip requirement was a bit more tricky (at least for me). It took me quite some time to figure out how to do this in WPF. The solution I’m going to show uses only XAML based code.

1. Integrating the Tooltip into the DataTrigger

We simply use our DataTrigger to automatically set theTooltip of a Control in case Notifications exist.

   <ToolTip x:Key="ValidationErrorTooltip" />

   <Style TargetType="Control">
        <Setter Property="Fx:ValidationBehavior.IsEnabled" Value="true" />
        <Style.Triggers>
            <DataTrigger
                Binding="{Binding Path=(Fx:ValidationBehavior.Notifications),
                Converter={StaticResource notificationConverter},
                RelativeSource={x:Static RelativeSource.Self}}" Value="true">
                <Setter Property="BorderBrush" Value="Red" />
                <Setter Property="BorderThickness" Value="2" />
                <Setter Property="ToolTip" Value="{StaticResource ValidationErrorTooltip}" />
            </DataTrigger>
        </Style.Triggers>
    </Style>

Now the UI looks really crappy. The tooltip is not recognizable as one.

2. Using a ControlTemplate to style the Tooltip

In order to shape the appearance of the Tooltip we can use Styles again. You can change the whole visual appearance of a Control using Styles and ControlTemplates. The template I defined consists mostly of a DockPanel containing a Label (which provides the tooltips caption) and a TextBlock (which will later contain the Notification messages).

    <Style x:Key="ErrorTooltipSyle" TargetType="ToolTip">
        <Setter Property="Template">
            <Setter.Value>
                <ControlTemplate TargetType="ToolTip">
                    <Border BorderBrush="Black" BorderThickness="1">
                        <DockPanel>
                            <Label DockPanel.Dock="Top"
                            	FontWeight="Bold"
                            	Background="Red"
                            	Foreground="White"
                            	Content="Validation Error" />
                            <TextBlock
                            	Padding="10"
                            	Background="White"
                            	Foreground="Black"
                            	TextWrapping="WrapWithOverflow" />
                        </DockPanel>
                    </Border>
                </ControlTemplate>
            </Setter.Value>
        </Setter>
    </Style>

    <!-- Notice the defined Style -->
    <ToolTip x:Key="ValidationErrorTooltip" Style="{StaticResource ErrorTooltipSyle}" />

    <Style TargetType="Control">
        <Setter Property="Fx:ValidationBehavior.IsEnabled" Value="true" />
        <Style.Triggers>
            <DataTrigger
                Binding="{Binding Path=(Fx:ValidationBehavior.Notifications),
                Converter={StaticResource notificationConverter},
                RelativeSource={x:Static RelativeSource.Self}}" Value="true">
                <Setter Property="BorderBrush" Value="Red" />
                <Setter Property="BorderThickness" Value="2" />
                <Setter Property="ToolTip" Value="{StaticResource ValidationErrorTooltip}" />
            </DataTrigger>
        </Style.Triggers>
    </Style>

Our UI now looks like this.

Not as crappy as before but we’re not finished yet, because we’re not displaying Notifications yet.

3. Define Databinding on the Tooltip

Defining the Databinding was probably the hardest step I had to take. The problem is that you need to get the NotificationCollection from the Control the ToolTip is displayed on. Being not a WPF pro figuring out how to do this took quite some time. Anyway, in order to get the Notification there isn’t much you need to do.

The trick is to bind against the property PlacementTarget on the ToolTip class itself. This property holds the reference to the Control on which the Tooltip is displayed. All we need to do is to add a Binding to the Style definition that sets the DataContext of the ToolTip to the related control.

    <Style x:Key="ErrorTooltipSyle" TargetType="ToolTip">
        ...
        <Setter Property="DataContext" Value="{Binding Path=PlacementTarget, RelativeSource={x:Static RelativeSource.Self}}" />
        ...
    </Style>

The next step we need to take is setting up the Binding for our attached property “Notifications”. Because a NotificationCollection can contain more than one Notification I used the ItemsControl for displaying them in the content area of the ToolTip.

    <Style x:Key="ErrorTooltipSyle" TargetType="ToolTip">
      <Setter Property="DataContext" Value="{Binding Path=PlacementTarget, RelativeSource={x:Static RelativeSource.Self}}" />
        <Setter Property="Template">
            <Setter.Value>
                <ControlTemplate TargetType="ToolTip">
                    <Border BorderBrush="Black" BorderThickness="1">
                        <DockPanel>
                            <Label DockPanel.Dock="Top"
                            	FontWeight="Bold"
                            	Background="Red"
                            	Foreground="White"
                            	Content="Validation Error" />
                            <TextBlock
                            	Padding="10"
                            	Background="White"
                            	Foreground="Black"
                            	TextWrapping="WrapWithOverflow">

                                <!-- This control displays our Notifications -->
                                <ItemsControl x:Name="notifications"
                                    HorizontalAlignment="Stretch"
                                    Margin="10"
                                    VerticalAlignment="Center"
                                    ItemsSource="{Binding Path=(Fx:ValidationBehavior.Notifications), Mode=OneWay}"/>

                             </TextBlock>
                        </DockPanel>
                    </Border>
                </ControlTemplate>
            </Setter.Value>
        </Setter>
    </Style>

Voila, our Notifications are finally displayed in the UI.

4. Styling the Notifications

In my initial post I showed a hyphen in front of each Notification. This is fairly easy to add, too. All you have to do is to define a DataTemplate for the Notification class and set it as the ItemTemplate of the ItemsControl we’re using.

    <!-- Very simple data template -->
    <DataTemplate x:Key="NotificationTemplate">
        <StackPanel Orientation="Horizontal">
            <TextBlock>-</TextBlock>
            <TextBlock x:Name="notification" Text="{Binding}" />
        </StackPanel>
    </DataTemplate>

    <Style x:Key="ErrorTooltipSyle" TargetType="ToolTip">
      <Setter Property="DataContext" Value="{Binding Path=PlacementTarget, RelativeSource={x:Static RelativeSource.Self}}" />
        <Setter Property="Template">
            <Setter.Value>
                <ControlTemplate TargetType="ToolTip">
                    <Border BorderBrush="Black" BorderThickness="1">
                        <DockPanel>
                            <Label DockPanel.Dock="Top"
                            	FontWeight="Bold"
                            	Background="Red"
                            	Foreground="White"
                            	Content="Validation Error" />
                            <TextBlock
                            	Padding="10"
                            	Background="White"
                            	Foreground="Black"
                            	TextWrapping="WrapWithOverflow">
                      		<ItemsControl x:Name="notifications"
                                    HorizontalAlignment="Stretch"
                                    Margin="10"
                                    VerticalAlignment="Center"
                                    ItemsSource="{Binding Path=(Fx:ValidationBehavior.Notifications), Mode=OneWay}"

                                    <!-- This uses configures our template for Notifications -->
                                    ItemTemplate="{StaticResource NotificationTemplate}" />

		                </TextBlock>
                        </DockPanel>
                    </Border>
                </ControlTemplate>
            </Setter.Value>
        </Setter>
    </Style>

DataTemplates are also the weapon of choice if you want to display errors in a different fashion than warnings (for instance by displaying a different icon). This is where we arrived.

Closing thoughts

What I like about the current solution is that it demonstrates in a nice way how different the programming model of WPF actually is compared to WinForms. The only imperative code we have is the code that transfers Notifications from our ViewModel into the logical tree. That’s it. The rest, the complete visual appeal of the Notifications, is a separated concern. Those two things can be changed independently from each other, even by different roles in a development team (Designer/Developer). Besides that I like the way the composition based WPF model helps my application code to stay focused and clean with only minimum implementation constraints on the ViewModel itself (the INotificationSource interface).

There’re certainly things to improve both in XAML and in the glue code but I consider it a good start to build on.

In case you’re interested in the complete code, I’ve uploaded it to a corner of the xUnit.BDDExtensions trunk. You can find it here . Feel free to do whatever you want with the code . . .

How the ViewModel notifies the UI

I defined an interface called INotificationSource for this. This interface defines only I member which exposes a NotificationCollection. NotificationCollection is just a standard ObservableCollection<Notification> with some additional bits in it (such as retrieving a collection of Notifications for a given source). By deriving from ObservableCollection you get the CollectionChangedEvent on the collection for free.

public interface INotificationSource
{
    NotificationCollection Notifications {get;}
}

In my current app I’ve got a Layer Supertype for ViewModels which implements this interface.

Glue code for transferring Notifications from the ViewModel into the logical tree

As I mentioned in the last post I’m using the Attached Behavior Pattern for transferring Notifications from the ViewModel to the related elements in the logical tree (When I say related I’m referring to the FrameworkElements bound to my ViewModel via DataBinding). The class responsible for the transfer is a DependencyObject derived class, called ValidationBehavior. This class defines two attached DependencyProperties, IsEnabled and Notifications.

    public class ValidationBehavior : DependencyObject
    {
        public static readonly DependencyProperty IsEnabledProperty;
        public static readonly DependencyProperty NotificationsProperty;

        static ValidationBehavior()
        {
            IsEnabledProperty =  DependencyProperty.RegisterAttached(
                                    "IsEnabled",
                                    typeof(bool),
                                    typeof(ValidationBehavior),
                                    new FrameworkPropertyMetadata(OnValidationBehaviorEnabled));

            NotificationsProperty = DependencyProperty.RegisterAttached(
                                    "Notifications",
                                    typeof(NotificationCollection),
                                    typeof(ValidationBehavior),
                                    new PropertyMetadata(null));
        }

        public static bool GetIsEnabled(DependencyObject host)
        {
            return (bool) host.GetValue(IsEnabledProperty);
        }

        public static void SetIsEnabled(DependencyObject host, bool isEnabled)
        {
            host.SetValue(IsEnabledProperty, isEnabled);
        }

        public static NotificationCollection GetNotifications(DependencyObject host)
        {
            return (NotificationCollection)host.GetValue(NotificationsProperty);
        }

        public static void SetNotifications(DependencyObject host, NotificationCollection notification)
        {
            host.SetValue(NotificationsProperty, notification);
        }

   }

The attached DependencyProperty “IsEnabled” is used to attach our behavior to the target element marked with the property. Notice the OnValidationBehaviorEnabled handler which is called when the value of the registered attached DependencyProperty has changed.

The attached DependencyProperty “Notifications” will later hold the collection of Notifications extracted from the ViewModel by our attached behavior. By having the NotificationCollection as an attached property you’re able to bind against it from XAML (as we’ll see in the following post).

If you recall the last post about this topic, maybe you remember that I didn’t actually set the attached property IsEnabled in the ViewModels XAML file. You could configure the behavior in the related XAML file but I didn’t want to do this for all my ViewModels. Because of this I decided to use Styles for this.

<!-- The global application class -->
<Application x:Class="Notifications.App"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <Application.Resources>
        <ResourceDictionary Source="Resources/Theme.xaml" />
    </Application.Resources>
</Application>

<!-- My XAML file containing the resources -->
<ResourceDictionary
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:Fx="clr-namespace:Notifications.Fx">

    <Style TargetType="Control">
        <Setter Property="Fx:ValidationBehavior.IsEnabled" Value="true" />
    </Style>

    <Style TargetType="TextBox" BasedOn="{StaticResource {x:Type Control}}" />

</ResourceDictionary>

When the Style is applied the IsEnabled attached property will be automatically set on all elements based on that style and this brings us into the position to hook into the elements events and access the elements data. The OnValidationBehaviorEnabled handler is actually straight forward.

        private static void OnValidationBehaviorEnabled(
            DependencyObject dependencyObject,
            DependencyPropertyChangedEventArgs args)
        {
            var frameworkElement = (FrameworkElement)dependencyObject;

            // Get the DataContext from the element. Mostly this DataContext is not directly
            // set on the element but rather derived from the parents DataContext
            var notificationSource = frameworkElement.DataContext as INotificationSource;

            if (notificationSource == null)
            {
                return;
            }

            // Clear related Notifications of an element when the element
            // got the focus.
            frameworkElement.GotFocus += ClearNotificationOnFocus;

            // Hook into the CollectionChanged event of the NotificationCollection.
            // I'm using a closure here in order to capture the FrameworkElement.
            notificationSource.Notifications.CollectionChanged += (sender, collectionChangedArgs) =>
            {
                var notifications = GetNotifications(notificationSource, frameworkElement);

                SetNotification(
                    frameworkElement,
                    notifications);
            };
        }

The anonymous event handler registered for the CollectionChangedEvent tries to get the collection of Notifications for the FrameworkElement.

        private static NotificationCollection GetNotifications(INotificationSource notificationSource, FrameworkElement frameworkElement)
        {
            return notificationSource.Notifications.AllNotificationsFor(frameworkElement.Name);
        }

As you can see this particular piece of code has a little quirk right now. It relies on the convention / assumption that the property on the ViewModel and the bound FrameworkElement share the same name. It was the easiest thing to do. It would also be easy to introduce another attached property for this in order to specify the name of the related ViewModel property. However this wouldn’t be 100% DRY because you’re most likely going to specify the property via the Binding MarkupExtension, too. I’m open to suggestions of how this correlation can be done better.

The last missing code piece is the handler which clears the Notification when it gets focus. It simply
sets the attached Notification property to null.

        private static void ClearNotificationOnFocus(object sender, RoutedEventArgs e)
        {
            var elementWithNotification = (FrameworkElement)e.OriginalSource;
            elementWithNotification.SetValue(NotificationProperty, null);
        }
    }

Closing thoughts

I hope you’re getting a feeling for what I wanted to show with this little post series. Today I talked mostly about how Notifications can be transfered from the ViewModel into the WPF tree. While the code currently has some pieces in it that imho should be refactored (correlation of the Notifications, CollectionChangedEvent currently reloads all Notifications), I hope you saw in this post that it’s relatively easy to add such an ability to your app infrastructure without a) having a base class constraint b) a lot of imperative code and c) doing a lot of configuration.

The next post will conclude this little series mostly with XAML stuff. We’re going to cover how to combine the different tools (DataTrigger, DataTemplates, ControlTemplates, Converter) that WPF offers in order to fire up a Tooltip containing all Notifications for an element.

CU next time . . .

This is the start of a small mini series about how I would currently approach the ‘Notification Pattern’ in a WPF application, using the default WPF practices and patterns. Think about it as a step by step guide for using DataBinding, Control-Templates, Styles, Resource-Inheritance, Converters and the Attached-Behavior-Pattern for displaying Notifications in the WPF-UI. (I guess most of this is also doable in Silverlight too, but I’ve never done anything with SL so I can’t say for sure). I’ve also prepared a little bit of sample code for this topic which will be download-able soon.

First,  some cautious warnings

I’m by no means a WPF-expert. I’m still in the learning phase. So,  if there are more obvious or intuitive solutions to the problem, or I’m plain wrong about this,  feel free to comment. I’m sure there is A LOT room for improvement.

What I’ve left out intentionally

I tried to strip everything unnecessary for the scope of the post from the code. This includes for instance IoC, Convention over Configuration, Code-Contracts, Expression-based Databinding setup and some base class or extension refactorings. Don’t get me wrong, I absolutely value those elements, but I wanted the example to be as easy as possible while being somewhat useful for a ‘real world’ application. The code might look a bit raw at at some edges because of this. So please keep that in mind before throwing with stones

Some other prerequesites

A while back I wrote a post about implementing the Notification-pattern using System.Componentmodel.DataAnnotations. It demonstrates the implementation of a generic validator based on the DataAnnotation attributes. Besides that, this post about the Attached-Behavior-Pattern will also be useful for this mini-series. Please give them a short visit if you haven’t read them yet.

The example scenario

The scenario I’m going to use for the example is a very simple sign up form. It contains two input fields for username / email and a ’sign-up’ button. It looks like this.

Rules associated with the fields are:

1. Username is required and must at least be 5 characters long.
2. Email is required and must contain a valid email address.

If any of the rules is broken, the related element should be visually highlighted . . .

. . . and when you hover over the element you’ll get a detailed description of the error from a tooltip.

I’m using the PresentationModel / MVVM pattern for the UI since it seems to be the default UI pattern in WPF.

This is how I would like my SignUpView to be

<Window x:Class="Notifications.SignUpView"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <Grid>
        <Grid.RowDefinitions>
            <RowDefinition Height="*"/>
        </Grid.RowDefinitions>
        <Grid.ColumnDefinitions>
            <ColumnDefinition Width="*"/>
        </Grid.ColumnDefinitions>
        <GroupBox
            Grid.Column="1"
            Grid.Row="1"
            Header="Sign up"
            BorderThickness="2"
            VerticalAlignment="Center"
            HorizontalAlignment="Center"
            MaxWidth="300"
            MaxHeight="600">
            <Grid>
                <Grid.RowDefinitions>
                    <RowDefinition />
                    <RowDefinition />
                </Grid.RowDefinitions>
                <Grid.ColumnDefinitions>
                    <ColumnDefinition Width="Auto"/>
                    <ColumnDefinition Width="Auto"/>
                    <ColumnDefinition Width="*"/>
                </Grid.ColumnDefinitions>
                <Label
                    Content="Username:"
                    VerticalAlignment="Bottom"
                    Margin="10,0,10,0"
                    Grid.Row="0"
                    Grid.Column="0" />
                <Label
                    Content="Email:"
                    VerticalAlignment="Bottom"
                    Margin="0,0,10,0"
                    Grid.Row="0"
                    Grid.Column="1" />
                <TextBox
                    Name="Username"
                    MinWidth="100"
                    MaxHeight="30"
                    Margin="10,0,10,10"
                    Grid.Row="1"
                    Grid.Column="0"
                    TabIndex="0"
                    Text="{Binding Path=Username, Mode=OneWayToSource, UpdateSourceTrigger=PropertyChanged}" />
                <TextBox
                    Name="Email"
                    MinWidth="100"
                    MaxHeight="30"
                    Margin="0,0,10,10"
                    Grid.Row="1"
                    Grid.Column="1"
                    Text="{Binding Path=Email, Mode=OneWayToSource, UpdateSourceTrigger=PropertyChanged}"
                    TabIndex="1" />
                <Button
                    MaxHeight="30"
                    Grid.Row="1"
                    Margin="0,0,10,10"
                    Grid.Column="2"
                    Content="Sign up!"
                    TabIndex="3"
                    Command="{Binding Path=SignUpCommand, Mode=OneWay}" />
            </Grid>
        </GroupBox>
    </Grid>
</Window>

This is how I would like my SignUpViewModel to be

public class SignUpViewModel : INotificationSource
    {
        private readonly NotificationCollection _notifications;
        private readonly DelegateCommand _signUpCommand;
        private readonly ISignUpService _signUpService;
        private readonly IValidator<SignUpViewModel> _validator;

        #region Constructors

        public SignUpViewModel(IValidator<SignUpViewModel> validator, ISignUpService signUpService)
        {
            _validator = validator;
            _signUpService = signUpService;
            _notifications = new NotificationCollection();
            _signUpCommand = new DelegateCommand(TrySignUp);
        }

        #endregion

        #region Properties

        [Required(ErrorMessage = "Field 'Username' is missing")]
        [MinimumStringLength(5)]
        public string Username
        {
            get;
            set;
        }

        [Required(ErrorMessage = "Field 'Email' is missing")]
        [MinimumStringLength(5)]
        public string Email
        {
            get;
            set;
        }

        public ICommand SignUpCommand
        {
            get { return _signUpCommand; }
        }

        public NotificationCollection Notifications
        {
            get { return _notifications; }
        }

        #endregion

        #region Private methods

        private void TrySignUp()
        {
            if (!IsValid())
            {
                return;
            }

            _signUpService.TrySignUp(Username, Email);
        }

        private bool IsValid()
        {
            Notifications.Clear();

            _validator.Validate(this, Notifications);

            return Notifications.ContainsErrors;
        }

        #endregion
    }

Did you notice it?

There is NO CODE in the View (Xaml and code behind) or the ViewModel which displays the Notifications.There’s also no base class for View or ViewModel where the code might be. What’s there on the other hand is only a collection of Notifications hanging of the ViewModel which is filled by the Validator. You might yourself now ask: Where is the damn glue code?

Yeah I know dumb question because I answered it mostly in the introduction of the post. The interesting thing is that it isn’t a single location. As you will see the responsibilities for achieving the effect are separated between several components.

In the next posts we’re going to take a look at

• how to use the Attached-Behavior-Pattern together with Styles and resource based inheritance in order to match the Notification (s) from the ViewModel to the related FrameworkElements in the logical WPF tree.
• how to use a DataTrigger on an Attached Properties in order to setup the Tooltip and showing the red border.
• how to bind the Tooltip correctly to the related Notification (s).

I hope I made you at least a bit curious . . .

Background

What I was particulary interested in was whether I could use it in order to implement some sort of declarative validation (for most of the standard cases) on my WPF ViewModels. The usage I wanted to achieve was something similar to the code shown in the next listing.

public class CustomerViewModel
{
       private IValidator<CustomerViewModel> _validator;
       private NotificationCollection _notifications;

       [Required]
       [MinLenght(3)]
       [DisplayName("First name")]
       public string FirstName { get; set; }

       [Required]
       [MinLenght(3)]
       [DisplayName("Last name")]
       public string LastName  { get; set; }

       [Required(ErrorMessage="The field Email address is mandatory")]
       [ValidEmail]
       [DisplayName("Email address")]
       public string EmailAddress { get; set; }

       public CustomerViewModel(IValidator<CustomerViewModel> validator)
       {
              _validator = validator;
              _notifications = new NotificationCollection();
       }

       public NotificationCollection Notifications { get { return _notifications;}}

       public bool IsValid()
       {
              _notifications.Clear();
              _validator.Validate(this, _notifications);
              return _notifications.ContainsErrors;
       }
}

Here is what I came up with in order to use the DataAnnotation Validators for this

First of all, some basics. I’m going to demonstrate a (very simple) implementation of the Notification pattern in this post. A detailed explanation this pattern is a bit out of scope for this post, but here’re some excellent resources for that:

• The Notification Pattern by Martin Fowler
• Domain centric validation with the Notification Pattern by Jeremy D. Miller

We’re starting with a base class for our Notifications. It’s a simple abstract class containing a message and a Source property. Besides that it contains an implicit conversion to string.

public abstract class Notification
{
       private readonly string _message;

       protected Notification() : this(string.Empty, string.Empty)
       {
       }

       protected Notification(string message) : this(string.Empty, message)
       {
              _message = message;
       }

       protected Notification(string source, string message)
       {
              Require.ArgumentNotNull(source, "source");
              Require.ArgumentNotNull(message, "message");

              _message = message;
              Source = source;
       }

       public string Source { get; protected set; }

       public override string ToString()
       {
              return _message;
       }

       public static implicit operator string(Notification notification)
       {
              return notification.ToString();
       }
}

Error is a simple class derived from Notification, which contains no additional code.

public class Error : Notification
{
       public Error(string source, string message) : base(source, message) { }

       public Error(string message) : base(message) { }
}

I’ve seen some people implementing the Notification pattern with a single Notification class and an enumeration specifying the type of the Notification (Error, Warning, Info, etc.) but I prever using classes for this. I think readability is way better (and shorter) using classes. Decide for yourself:

bool isError = notification is Error;
//versus
bool isError = notification.Severity == Severity.Error;

It’s very rare that you only have to validate one element / property. Mostly we’re dealing with more than one elment beeing validated. Because of that it’s useful to have a container or collection for Notifications. This gives you a nice place for some additional functionality.

public class NotificationCollection : ObservableCollection<Notification>
{
       public bool ContainsErrors
       {
              get { return this.Exists(notification => notification.IsOfType<Error>()); }
       }

       public bool ContainsWarnings
       {
              get { return this.Exists(notification => notification.IsOfType<Warning>()); }
       }

       public IEnumerable<Notification> AllNotificationsFor(string nameOfSource)
       {
              return this.Where(notification => string.Equals(notification.Source, nameOfSource, StringComparison.Ordinal));
       }
}

While the first properties are pretty obvious, the last method probably needs some explanation. It finds all notifications for a given source name. The source in my implementation is the name of the property on the ViewModel that was validated. Im currently using a little convention here. Properties in WPF views have the same name as the ViewModel properties they’re bound to. This makes it relatively easy to correlate those two things (meaning deciding which Notification belongs to which UIElement).

Having set this up, let me walk you through the validator implementation.

A Validator<T> using DataAnnotations

public class Validator<TElement> : IValidator<TElement>
{
       private static readonly IEnumerable<PropertyValidator> Validators;

       static Validator()
       {
              var properties = typeof (TElement).GetProperties(BindingFlags.Instance | BindingFlags.Public);

              Validators = from property in properties
                     where property.IsMarkedWith<ValidationAttribute>()
                     select new PropertyValidator(property);
       }

The static constructor of the Validator class uses reflection to find all marked properties of the target type specified via the generic type argument TElement. It searches for properties marked at least with one derivate of the System.ComponentModel.DataAnnotations.ValidationAttribute and creates a PropertyValidator for each match.

#region IValidator<TElement> Members

public void Validate(TElement element, NotificationCollection notifications)
{
       Validators.Each(entry => entry.Validate(element, notifications));
}

#endregion

The actual validation happens inside the Validate method. This method simply uses all known PropertyValidators in order to validate the target object.

#region Nested type: PropertyValidator

private class PropertyValidator : IValidator
{
       private readonly PropertyInfo _property;
       private readonly string _propertyDisplayName;
       private readonly IEnumerable _propertyValidators;

       public PropertyValidator(PropertyInfo property)
       {
              _property = property;
              _propertyDisplayName = GetDisplayName(_property);
              _propertyValidators = GetValidators(property);
       }

A PropertyValidator does some things internally when it’s created. First it determines the name for the validated element which should be used in the UI. Since you probably don’t want the user to see something like “FirstName is required” or “SelectedCountry is required” I’m using
System.ComponentModel.Design.DisplayNameAttribute here which can be used to specify a UI-friendly name. If no DisplayNameAttribute is specified on a property the validator uses the property name instead.

private static string GetDisplayName(PropertyInfo property)
{
       if (property.IsMarkedWith<DisplayNameAttribute>())
       {
              return property.GetAttribute<DisplayNameAttribute>().DisplayName;
       }

       return property.Name;
}

After it has determined the UI friendly display name it extracts all DataAnnotations ValidationAttributes from the property. (Note: GetAttributes is an ExtensionMethod. Same applies to IsMarkedWith and GetAttribute)

private static IEnumerable<ValidationAttribute> GetValidators(PropertyInfo property)
{
       return property.GetAttributes<ValidationAttribute>();
}

And here is the rest, which brings the whole thing to life. This code simply extracts the value from the property, iterates over all known ValidationAttributes and checks the value with them. When a ValidationAttribute signals that a value is not valid, an error message is formatted with the UI-friendly name I talked earlier about and the whole thing is stored as an Error.

#region IValidator Members

public void Validate(TElement element, NotificationCollection notifications)
{
       var value = _property.GetValue(element, new object[] {});

       _propertyValidators.Each(validator =>
       {
              if (!validator.IsValid(value))
              {
                     string formmattedErrorMessage = validator.FormatErrorMessage(_propertyDisplayName);
                     notifications.Add(new Error(_property.Name, formmattedErrorMessage));
              }
       });
}

#endregion

Bottom line

It’s pretty easy to combine the existing functionality provided by DataAnnotations with the Notification Pattern. It just took me an hour to get to a working solution which I consider pretty fast and which imho indicates an easy to use framework. As you can imagine the hard part isn’t getting the Notifications out of the model, but rather finding an unrepetative, intuitive way to display them in the UI. In the past I’ve missed several times the pit of success regarding this aspect. However I’m really confident that my current solution is really Dry AND easy to use.

In one of the next posts I’m going to show how to combine Attached Behavior, Styles and Templates in order to bring the Notifications described in this post to the applications front door, the UI . . .

Anyway, here is what the pattern actually does:

The Attached Behavior Pattern uses the moment when an attached DependencyProperty is attached to a DependencyObject in order to wire event handlers to it. With this you’re able to extend the behavior of elements in the WPF trees with arbitrary code.

Let’s take a look at how this can be achieved. First of all we need a class deriving from DependencyObject in order to be able to provide an attached DependencyProperty. It uses the standard pattern of registering the IsEnabled DependencyProperty in the static constructor (which is a bit clunky, btw).

    public class MyBehavior : DependencyObject
    {
        public static readonly DependencyProperty IsEnabledProperty;

        static MyBehavior ()
        {
            IsEnabledProperty = DependencyProperty.RegisterAttached(
                "IsEnabled", //Name of the property
                typeof(bool),//Type of the attached property
                typeof(MyBehavior),//Type of the class that provides the property
                new FrameworkPropertyMetadata(false)); //Default value
        }

        public bool IsEnabled
        {
            get { return this.GetValue<bool>(IsEnabledProperty); }
            set { SetValue(IsEnabledProperty, value); }
        }
    }

Pretty standard stuff so far. However you can use another constructor of FrameworkPropertyMetdata in order to supply a callback which is called when the value of the attached property changes.

	IsEnabledProperty = DependencyProperty.RegisterAttached(
                "IsEnabled", //Name of the property
                typeof(bool),//Type of the attached property
                typeof(MyBehavior),//Type of the class that provides the property
                new FrameworkPropertyMetadata(false, OnBehaviorEnabled)); //Default value + Callback

Next thing we need to do is to configure this attached property on the DependencyObject we want to attach behavior to. This is preferably done in XAML. You’ve got at least two options for doing the configuration. The first option is to set your attached property in the XAML file of a UserControl, Page or Window directly at the source, the element you want to attach behavior to.

<TextBox myNamespace:MyBehavior.IsEnabled="true" />

The other option is to use the the power of styles (an area were WPF really shines imho) in order to set it for all elements to which a style is applied.

 <Style TargetType="TextBox">
        <Setter Property="myNamespace:MyBehavior.IsEnabled" Value="true" />
 </Style>

Personally I very much vote for the second option, because it enables you to specify the attached behavior in a single place in contrast to configuring it at several places in your solution. Don’t repeat yourself, unless you really need to.

Now, fasten your seatbelts. This is were the fun begins. When the WPF / Silverlight infrastructure loads the compiled baml from the resources and builds the element tree from it (and with this attaches our new property to the specified elements) the callback method gets called.

        private static void OnBehaviorEnabled(
            DependencyObject dependencyObject,
            DependencyPropertyChangedEventArgs args)
        {
            TextBox textBox = (TextBox)dependencyObject;

            textBox.LostFocus += (s,e) =>
            {
	          //Put your little piece of magic here
            };

        }
    }

With first parameter of the callback you get a reference to the DependencyObject to which our attached property has been attached to. You’re now able to wire all sort of event handlers to the DependencyObject and are able to execute arbitrary code when the event occurs.

Here ends our journey for today. Attached Behaviors is a really nice technique which enabled me to do something that I always wanted to have in my WinForms apps but never found a satisfiing way to implement it (just a bit patience, I’m going to blog about it soon). I think it will be interesting to see
how this pattern is used in the future. While new patterns always have the tendency to be overused, I think that this particular pattern can enable lots of valuable things . . .

I’ve read several times about how steep the learning curve is and must admit, yeah that’s probably right. At least I’ve experienced it that way. BUT, here is the interesting side node: That’s mostly not because of the difficulty or complexity of the technology itself. A lot of my problems arose because of the way how I tried to approach WPF.

Having spend most of my professional work with WinForms seems to have left some traces. I remember lots and lots of situations where I thought to myself: “Why is that so hard? In WinForms you must simply . . .”, “This TreeView just plain sucks” or “Mh, where is the Dock property on a Control?”. Makes me smile now when I think about it. What I basically experienced is THAT IT’S HARD TO DO WINFORMS DEVELOPMENT WITH WPF.

WPF was never designed to be WinForms V2. Neither was it designed to have a similar programming model. After realizing this here is a little yoda-eske advice for WPF-learners like me:

Don’t let you’re WinForms knowledge stand in your way. Try to really understand the programming model and the intentions of WPF first and constantly review whether problems you experience while learning WPF come from trying to do the things the way you’re used to in WinForms.

Once I’ve understood that I really felt that I made a big leap forward. WPF is such a rich, enjoyable technology if you stick with it long enough. Sadly I’m currently not participating in a WPF or Silverlight project (like so may others), but I’ve high hopes.

Better times are coming . . .