View/ViewModel Interaction - Bindings, Commands and Triggers

Lets now look at the XAML:

<fxui:View
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
  xmlns:fxui="clr-namespace:SilverlightFX.UserInterface;assembly=SilverlightFX"
  xmlns:local="clr-namespace:Translate"
  x:Class="Translate.TranslateWindow">
  
  <fxui:View.Resources>
    <fxui:Command x:Key="translateCommand" Method="Translate" />
    <fxui:Command x:Key="speakCommand" Method="Speak" />
  </fxui:View.Resources>

  <Grid>
    <fxui:VStackPanel Margin="10" ChildAlignment="Center" ChildSpacing="4">
      ...

      <TextBlock Style="{StaticResource labelText}"
        Text="Enter some text to translate:" />
      <TextBox x:Name="inputTextBox" Style="{StaticResource inputText}"
        AcceptsReturn="True" Width="400" Height="100"
        HorizontalScrollBarVisibility="Disabled" VerticalScrollBarVisibility="Auto"
        Text="{Binding Text, Mode=TwoWay}" />

      <TextBlock Style="{StaticResource labelText}"
        Text="Select a language:" />
      <ComboBox Width="100" ItemsSource="{Binding Languages}"
        DisplayMemberPath="Name"
        fxui:Commands.Selection="{StaticResource translateCommand}" />

      <Border Style="{StaticResource displayArea}" Margin="0,10,0,0">
        <TextBlock x:Name="outputLabel" Style="{StaticResource labelText}" Width="400"
          Text="{Binding TranslatedText}" />
      </Border>
      
      <Button Width="100" Height="23"
        fxui:Commands.Click="{StaticResource speakCommand}"
        Content="Say It!" />
    </fxui:VStackPanel>

    <MediaElement x:Name="mediaPlayer" IsMuted="False" AutoPlay="True">
      <fxui:Interaction.Triggers>
        <fxui:ModelEventTrigger EventName="AudioStreamLoaded">
          <local:PlayWaveAudio />
        </fxui:ModelEventTrigger>
      </fxui:Interaction.Triggers>
    </MediaElement>
  </Grid>
</fxui:View>

The interesting bits are in bold. But first notice, what isn't there. The view doesn't need to say anything about its view model explicitly. The <fxui:View> class (which derives from UserControl) implements the convention as I described in my prior blog post, which causes TranslateWindowModel to automatically be created for the TranslateWindow view, and set as its Model as well as DataContext.

Bindings

You can see the Text property of inputTextBox and outputLabel bound to Text and TranslatedText properties of the view model using a XAML {Binding}, as you'd expect (mentioned here for completeness).

Commands

Now comes the interesting part. Generally, I've seen commands implemented in the view model using helpers like a DelegateCommand implementation. However this in my opinion adds noise to what ought to be a simple class with simple methods. I see commands as glue between the UI (events on controls) and operations (methods on view model), rather than state of the application to be exposed as properties on a view model. So in the example above I've declared some command instances in resources that the UI can use. Each <fxui:Command> object is a command which implements the standard ICommand interface, and is responsible for invoking the specified method. This is analogous to bindings which are responsible for retrieving or setting properties.

It is interesting to place a command in the resource if multiple events/controls can trigger the same command. A command can also be declared inline if its not meant to be shared (again just like binding). For example:

<Button>
  <fxui:Commands.Click>
    <fxui:Command Method="Speak" />
  </fxui:Commands.Click>
</Button>

And finally, once markup extension are enabled in Silverlight, I'd like to write (again, just like bindings):

<Button fxui:Commands.Click="{Command Speak}" />

By default <fxui:Command> executes a method it finds on its DataContext. However you can bind its Target property to any other object, such as another element within the view. Also, behind the scenes a command bound to the Speak method will look for the existence of a CanSpeak property on the same target object, and subscribe to property change notifications on that property, in order to accurately implement the CanExecute property of ICommand.

The other interesting thing going on here is the way commands are hooked up. I've used an attached property, Commands.Click - this is there for Silverlight 3 support where Button doesn't have an intrinsic Command property (which does exist in Silverlight 4). Additionally, I've applied the pattern to other scenarios - for example, I also implemented things like Commands.Selection that can be specified on any Selector-derived control such as ListBox or ComboBox. This allows invoking a view model operation when the selection changes. Folks have often asked why commands are just restricted to buttons and click events. They don't have to be.

Another interesting tidbit, by default, the selected item of the Selector is passed in as the command parameter, in case your view model operation works needs access to what was selected. So for the default case, you don't have to also specify the Commands.Parameter property. In the example above, the Translate method on the view model needs the selected Language and that just works.

And to where I am really going with commands as objects in the UI - you can attach behaviors to commands - eg. to perform pre and/or post logic. For example, I can have a Login behavior that automatically pops up a login dialog, allow the user to login if they click on a command that requires authentication, and upon successful login, let the command invoke the view model. Now the view model doesn't have to concern itself with interrupting its processing to show a login dialog, collect credentials etc.

I really see commands as a powerful building block in the world of XAML. I also demoed this approach in my MIX talk, so if you're looking for more samples, check out the post I did around the BookClub application from my MIX session.

Triggers

Sometimes a view model needs to raise notifications, that a view should handle and do something in response, esp. when these can't be modeled as properties and property change notifications.

For example, in the application here, the view model raises an event to indicate the audio stream for the translated text has been loaded. This could not be modeled as a property, since the MediaElement doesn't have a property of type MediaStreamSource. It instead has a method called SetSource. So something in the view needs to call that method.

Enter triggers and actions. The combination basically is a construct that lets you say, "when this happens, do that". In the code above I've attached a ModelEventTrigger to the MediaElement. The trigger listens to the Model, and subscribes to the specified event, AudioStreamLoaded. When that event is raised by the view model, the trigger invokes its action(s). In this case the PlayWaveAudio action is invoked, which receives the audio stream from the event, creates a MediaStreamSource after parsing the wav data returned from the translation service, and calls on the associated MediaElement's SetSource method to play the audible version of the translated text.

Summary

The core view model pattern is simple - it is all about authoring a vanilla class that encapsulates what is interesting in your application, and then consuming that via declarative building blocks in XAML.

For more view model reading, I also have posts on implementing modal dialog scenarios and MVC-based navigation in conjunction with the view model. And I am sure I'll have a few more view model posts over time, so stay tuned, and as always, do share thoughts, comments, suggestions and questions below.