David Hill's WebLog : Helix

Custom Content Loaders in Silverlight 4.0

dphill — Thu, 24 Dec 2009 15:51:13 GMT

Silverlight 3.0 supports navigation by providing a Frame control into which you can load various pages as the user clicks on hyperlink controls in the application’s UI. Each page is specified by a Uri. As navigation takes place, the browser’s history and address bar is updated with this Uri. This allows the user to use the browser’s forward and back buttons to navigate around within the Silverlight application or to use deep links. You can map ‘friendly’ Uri’s to real page Uri’s so that the browser’s address bar doesn’t display the internal details of your application’s UI structure.

The Silverlight 3.0 navigation framework has some very interesting capabilities, but it does have some limitations too. One of these limitations is that all of the pages that can be navigated to have to be defined in the application’s primary XAP file. For composite applications, that typically consist of multiple XAP files, this has proven to be quite a problem. Various workarounds have been proposed but they are all pretty clunky. The underlying problem is that the Silverlight 3.0 navigation framework doesn’t provide any extensibility hooks to implement this capability properly.

The Good News

Happily, this is about to change in Silverlight 4.0, which will allow you to specify a Content Loader for each Frame instance:

   1: myFrame.ContentLoader = new CustomContentLoader();

The content loader is responsible for loading whatever content is associated with the target Uri. By giving folks the ability to create custom content loaders of their own, Silverlight 4.0’s navigation framework opens up some very interesting extensibility options. A custom content loader, for example, can remove the need for clunky shims and pass-through loader pages when navigating to pages located in other XAP files. They can also allow you to use navigation Uri’s which don’t necessarily have to map directly to UI content, or allow you to control the target page’s construction (so you can hook up it’s ViewModel), etc.

The Bad News

There is a rather large drawback with custom content loaders though: they are executed asynchronously. This makes them quite tricky to implement. A custom content loader implements the INavigationContentLoader interface which includes Begin and End methods and uses an IAsyncResult object to coordinate the asynchronous interaction between the Frame and the content loading logic. This asynchronous call pattern is known as the .NET Asynchronous Programming Model (APM). It’s notoriously tricky to implement properly – not least of which because you have to account for the 3 or 4 ways in which the caller can execute the call, and you have to handle exceptions, cancellations and wait handles very carefully.

So why is navigation executed asynchronously you may ask. That’s a very good question! I was involved in the early design discussions for the Silverlight navigation framework and argued against an asynchronous model for a couple of reasons. My main argument was that navigation invariably means you have to construct the new UI to which you’re navigating, and this has to happen synchronously on the UI thread. My other argument was to do with user experience – more on this later.

Ah, yes, (so the counter-argument went) but what happens if you want to download some content/data from the host web site, or make a web service call, or load data from a database, or maybe do some complex calculation – you can’t tie up the UI thread! These are all valid things to do in an application of course, just not within the navigation operation itself!!! Apart from anything else, these are pretty advanced scenarios and by far the majority of navigation scenarios will just involve mapping Uri’s to UI content which just needs to be loaded (on the UI thread!!). In addition, all of these scenarios can be achieved fairly easily on top of a synchronous navigation model, and in a way that makes for a better user experience too.

Ok, rant over. I feel much better now :-) INavigationContentLoader is what it is. The Silverlight folks have worked hard to open up the navigation framework a little and given us a key extensibility point. We just have to try and leverage it as best we can…

So, in this post I’ll describe the implementation of a base class (ContentLoaderBase) that can be used to easily implement custom content loaders in Silverlight 4.0. You can use this base class to implement any number of different content loaders, including synchronous content loaders or asynchronous content loaders that download content in the background or that use a background thread for background processing. Hopefully this base class will provide you with a reasonable starting point for implementing whatever type of content loader you need in your application. At the end of this post I’ll talk briefly about how the ContentLoaderBase base class works.

You can download the sample code here.

It’s built on Visual Studio 2010 Beta 2 and Silverlight 4.0 Beta. The sample shows how to configure and use various synchronous and asynchronous content loaders and their effect on navigation. You can switch between the sample content loaders in MainPage.xaml.cs.

Implementing a Synchronous Content Loader

The ContentLoaderBase base class provides a small number of virtual methods. You can implement a synchronous or an asynchronous custom content loader simply by overriding the right methods. In the simple (and most common) case of an synchronous content loader, you simply need to override a single method – LoadContentSync – which looks like this:

   1: protected override object LoadContentSync( Uri targetUri,

   2:                                            Uri currentUri )

   3: {

   4:     return new ControlOrPage();

   5: }

In this method you simply create or load whatever UI content you need based on the new (and maybe the current) Uri. You can do this in any number of ways – using a switch statement or using a lookup table for example. The important thing to note is that this method is called on the UI thread so you don’t have to worry about creating UI content or making cross-thread calls.

Of course, since the call is made on the UI thread, you shouldn’t do crazy things like make a network call or do a lengthy calculation in this method. If you need to do anything like that then you may need an asynchronous content loader (though I’ll argue later that even if you do need to do anything like this you shouldn’t do it during navigation). In the meantime here’s how you can do it using the ContentLoaderBase class…

Implementing an Asynchronous Content Loader

You can implement an asynchronous content using the ContentLoaderBase class by overriding two virtual methods (and implementing one or two callbacks). The first method to override is the GetLoadBehavior method which defines whether the navigation operation for a particular Uri is synchronous or asynchronous (the default value is synchronous which is why we didn’t need to override this method in the synchronous case above).

   1: protected override LoadBehavior GetLoadBehavior( Uri targetUri )

   2: {

   3:     // Content is loaded asynchronously for all Uris.

   4:     return LoadBehavior.Asynchronous;

   5: }

In this example, navigation for all Uri’s is asynchronous, though we could of course have some Uri’s handled synchronously and some handled asynchronously (which is useful when, for example, we’ve cached content that was previously downloaded asynchronously so that subsequent navigations can be handled synchronously).

The other method you need to override is the LoadContentAsync method. This is where you initiate whatever asynchronous operation you need. When that operation is completed, you simply need to call the LoadContentAsyncComplete method in the base class to complete the navigation operation.

   1: protected override void LoadContentAsync(

   2:                     ContentLoaderAsyncResult asyncResult )

   3: {

   4:     // Initiate asynchronous operation here...

5:

   6:     // When the asynchronous operation is completed, call the

   7:     // LoadContentAsyncComplete method on the base class to

   8:     // complete the navigation operation.

   9: }

Broadly speaking, there are two types of asynchronous operations that you might want to do when loading content during a navigation operation. The first involves downloading some form of content, data or configuration from the host web site. The second involves performing some form of processing or calculation on a background thread.

Either way, once the async operation is completed you will still need to load or create the actual UI content to which you’re navigating on the UI thread. The way you do that in each of these two scenarios are slightly different and may require you to implement one or more callbacks. Let’s look at each of these scenarios in turn…

Downloading Content During Navigation

Retrieving or sending data from the host web site is a common scenario in Silverlight. The Silverlight WebClient class makes this fairly straightforward by providing an asynchronous event-based callback mechanism – you can start the download or upload process and the WebClient class will call you back when its complete. They key feature of this class is that the callback happens on the UI thread, which in turn means that you don’t have to worry about cross-thread UI access. It’s a pity that the navigation framework didn’t adopt the same event-driven approach… Ho hum…

To use the WebClient class in a content loader, we simply need to start a download process (or whatever we need) in the LoadContentAsync method and specify a callback method. Since the callback method is called on the UI thread we can load or create whatever UI content we need there. The completed sample looks something like this:

   1: protected override void LoadContentAsync(

   2:                             ContentLoaderAsyncResult asyncResult )

   3: {

   4:     // Use the WebClient class to download a file from the

   5:     // web server. This is an asynchronous method call and

   6:     // will return immediately.

   7:     webClient.OpenReadAsync(

   8:                 new Uri( "NavigationData.xml", UriKind.Relative ),

   9:                 asyncResult );

  10: }

11:

  12: private void OnOpenReadCompleted( Object sender,

  13:                                   OpenReadCompletedEventArgs e )

  14: {

  15:     ContentLoaderAsyncResult asyncResult =

  16:                     (ContentLoaderAsyncResult)e.UserState;

17:

  18:     // Since the WebClient callback is on the UI thread,

  19:     // we can create the UI we're navigating to here.

  20:     Object content = new ControlOrPage();

21:

  22:     // Inform the base class that the async request has

  23:     // been completed.

  24:     base.LoadContentAsyncComplete( content, asyncResult );

  25: }

Notice how the UI content that was created in the callback method is passed back to the base class via the LoadContentAsyncComplete method call. The base class then completes the asynchronous navigation operation and passes the content to the Frame.

Background Processing During Navigation

The other scenario where you might want to use an asynchronous content loader is where you want to use a background thread to perform some kind of calculation or background process. In this case, the LoadContentAsync method might look something like this:

   1: protected override void LoadContentAsync(

   2:                             ContentLoaderAsyncResult asyncResult )

   3: {

   4:     // Use the thread pool to queue up a background operation.

   5:     ThreadPool.QueueUserWorkItem( BackgroundTask, asyncResult );

   6: }

Where BackgroundTask is the method that defines the background process. This method will of course be called on the background thread, not the UI thread, so when the calculation is finished how do we load the UI content that we need to navigate to? To do that, when we inform the base class that the calculation has finished, we provide another callback. The base class makes sure that this callback will be called on the UI thread so we can load our UI content there. The completed sample looks something like this:

   1: private void BackgroundTask( Object state )

   2: {

   3:     ContentLoaderAsyncResult asyncResult =

   4:                 (ContentLoaderAsyncResult)state;

5:

   6:     // Simulate some lengthy calculation or process.

   7:     Thread.Sleep( 4000 );

8:

   9:     // We can't create the necessary UI content

  10:     // here because we're on a background thread.

  11:     // So we create the UI in a callback method.

  12:     // The base class will call the callback on the UI thread.

  13:     base.LoadContentAsyncComplete( LoadContentUICallback,

  14:                                    asyncResult, asyncResult );

  15: }

16:

  17: private Object LoadContentUICallback( Object callbackState )

  18: {

  19:     Debug.WriteLine( "LoadContentUICallback" );

20:

  21:     ContentLoaderAsyncResult asyncResult =

  22:                 (ContentLoaderAsyncResult)callbackState;

23:

  24:     // Since THIS callback is on the UI thread, we can

  25:     // create the UI we're navigating to here.

  26:     return new ControlOrPage();

  27: }

TODO: Cancelation

The above code snippets are simplified a little to show you the essentials. If you have an asynchronous content loader you will find that a navigation operation will often be canceled. To implement an asynchronous content loader properly you will therefore have to account for cancelation.

Why is navigation canceled so often? Because the navigation framework does not provide any built-in mechanism to give feedback to the user during an asynchronous navigation operation. Since the user expects navigation to be instantaneous, they have a tendency to click the navigate button or hyperlink control multiple times, and each time they do, the previous navigation operation will be cancelled. So it’s very important to handle cancellations properly, otherwise you can easily run into tricky-to-handle exceptions during navigation. The irony of course, is that asynchronous navigation was meant to improve the user experience…

To illustrate the effects of network latency or lengthy processing during navigation, the sample code includes artificial delays. For the download sample, a HTTP handler is used to introduce an artificial delay during the download of the dummy file. Similarly, the background thread sample includes a 3 second Thread.Sleep in the background task method.

When navigation is asynchronous, you’ll quickly notice that clicking on the navigation links during an existing navigation operation will cause the previous navigation operation to be canceled. The sample code shows how you might handle this situation but there are some complications that have not yet been ironed out (see the comments in the code for more details). In the download case you will need to somehow cancel the previous download operation. In the background thread case you will have to find a way to abort or cancel the calculation or background process gracefully if navigation is cancelled…

ContentLoaderBase Class Implementation Details

The key to the ContentLoaderBase Class is the object that implements the IAsyncResult interface. For that I leveraged the excellent coding skills of Jeffery Richter and his MSDN magazine article (here) from a few years back. That article and the accompanying code, describes many of the subtle details that you have to worry about when implementing the APM. With the IAsycnResult object implemented properly, the ContentLoaderBase class ‘simply’ has to make sure that the right virtual methods are called in the right order and that the LoadContentUICallback is executed on the UI thread.

An Easier Approach

The ContentLoaderBase class simplifies things quite a bit, especially when implementing a synchronous content loader. But I think you can probably see that asynchronous content loaders are still a little complicated to implement properly. I’m sure that I have not even begun to iron out all of the subtle issues that inevitably show up when you’re doing anything asynchronously (e.g. cancelation as noted above).

For reasons of complexity, plus the bad user experience that can result, I would recommend using only synchronous content loaders wherever possible. But what about those situations where you absolutely need to download or calculate something during navigation? My advice is to do these things outside of the navigation framework and to do them in the target page itself.

So for example, for the two scenarios above, you would navigate to a page (synchronously) that will then download the content or perform the calculation (in its ViewModel of course). Furthermore, while the page is downloading the content or performing the calculation, it can provide visual feedback to the user! To the user, the navigation is instantaneous, even though the target page might take a while to initialize itself. By providing visual feedback while this happens you will likely prevent the user from getting frustrated and repeatedly clicking the navigate button or link.

I’ll explore this approach, plus some other interesting things you can do with a custom content loader, in a future post…

The Breadcrumb Navigation Pattern

dphill — Thu, 15 Oct 2009 22:16:34 GMT

The Breadcrumb Navigation pattern provides a visual representation of the path the user took as they navigated to a particular state in an application. It provides context so the user can see where they are logically within the application structure, and it allows them to quickly navigate that structure by jumping straight to previous breadcrumbs.

Perhaps the most common example of the breadcrumb navigation pattern is Windows Explorer – as you navigate the file system, the breadcrumb control at the top of window displays the path to the current folder, with each folder in the chain displayed as a button. You can jump directly to any of the parent folders by clicking on it.

You often see the pattern used in web sites, especially ones where the user is navigating through a lot of hierarchical data. For example, a lot of ecommerce site allows the user to browse the product catalog by drilling into product categories and by specifying search criteria and filters. Here’s a good example from GuitarCenter.com – you can navigate around within the product catalog by product category and filter the view by price or manufacturer.

The Breadcrumb Navigation Pattern in Helix

This post describes how you can implement the breadcrumb navigation pattern in Helix, my prototype navigation framework for Silverlight. You can download the latest version of Helix from here, and run the sample described below here.

The BreadcrumbBar Control

Implementing the Breadcrumb Navigation pattern in Helix turned out to be quite straightforward. The main element is the BreadcrumbBar control. This control displays the breadcrumbs as the user navigates within an associated Frame. The user can click on any of the breadcrumbs causing the associated Frame to navigate back to the corresponding point in the navigation history.

The BreadcrumbBar control is actually a sub-classed and re-templated ListBox control that is bound to the target Frame's journal. As the user navigates between Pages in the target Frame, journal entries are added to the journal. Each journal entry is represented in the BreadcrumbBar control as a ListBox item. The BreadcrumbBar control's template displays each item horizontally as a chevron, along with the corresponding page title. The most difficult part to getting this to work is the control template itself. I used Blend 3.0 to edit the template so even that wasn't that difficult. I also made a couple of changes to the Helix library itself to support breadcrumb style navigation in the Journal. More details on this below.

The Sample Application

Patterns & practices guidance is organized by four high-level focus areas – Fundamentals, Client, Server and Services. Within each area there can be a number of sub-categories (such as security, performance, etc), and within sub-categories there is the guidance itself. Since the catalog is hierarchical, it’s a natural fit for the breadcrumb navigation pattern. I’ll describe a simple application that uses the BreadcrumbBar control and Helix to allow the user to browse through the patterns & practices guidance catalog. You can see the completed application and the BreadcrumbBar control in action here.

This is a simple application that has a simple shell that contains a BreadCrumbBar control and a Frame control in a grid:

<BreadcrumbBar Grid.Row="1"

       NavigationTarget="{Binding ElementName=frame}"

       ClearForwardStack="False"/>

<Frame x:Name="frame" Grid.Row="2"

    NavigationUIVisibility="Hidden" InitialUri="HomePage"/>

The BreadcrumbBar control is connected to the target Frame through simple data binding. Since we’re using the BreadcrumbBar control we don’t need the Frame’s back/forward buttons so we can hide the Frame’s navigation UI. The Frame navigates to the HomePage on startup. That’s pretty much it. I’ll talk about the ClearForwardStack below. You can tweak some of the visual aspects of the BreadcrumbBar control, or even replace the control template, to suit your application’s UI style.

How Does It Work?

The BreadcrumbBar control is just a sub-classed and re-templated ListBox. When the NavigationTarget property value is set, it sets the base class ItemSource to the journal back stack.

this.ItemsSource = NavigationTarget.Journal.BackStack;

If the user changes the current selection (i.e. by clicking on a previous breadcrumb), the target Frame is navigated to the associated Uri. To support this I added two new methods to the IJournal interface – GoBackTo and GoForwardTo. These two methods allow the journal to navigate directly to an entry that’s in the back stack or the forward stack, without having to navigate backwards or forwards multiple times.

NavigationTarget.Journal.GoBackTo( entry, ClearForwardStack );

Two other things to note:

The current selection of the underlying ListBox tracks the last entry in the journal. In other words, as the user navigates to new pages within the Frame, a journal entry for it is added and it becomes the current selection in the BreadcrumbBar control.
The ClearForwardStack parameter is used to control how the journal’s forward stack is affected when the user clicks on a previous breadcrumb. Most often you’ll want the forward stack to be cleared, and this is the default. Sometimes you might want to keep the forward stack intact so the user can go forward again. To enable this, just set the ClearForwardStack parameter to false.

What’s Next For Helix?

Now that Silverlight 3.0 supports navigation, the need for Helix is not as great as it was. I actually wrote the original specs for the Silverlight 3.0 Navigation feature. The original design in fact was very similar to Helix, but due to a number of constraints the design evolved and became a little less extensible than originally planned. There are key extensibility points that Helix provides which enable a whole host of interesting scenarios that are difficult or impossible to achieve with the current Silverlight navigation implementation. I’ve really only scraped the surface of these in this series so I’ll continue to evolve Helix in order to explore these scenarios. I’m working with the Silverlight team to explore ways in which these key extensibility points can be opened up in upcoming Silverlight releases.

In the meantime, if you’re building a Silverlight application that requires navigation functionality, you should use the Silverlight 3.0 navigation framework since it’s robust and fully supported. Hopefully, the need for Helix will go away altogether once the Silverlight navigation framework is more extensible.

Blend Behaviors

dphill — Sat, 26 Sep 2009 02:18:59 GMT

Expression Blend 3 includes a number of very cool new features (see here for a good summary). But there are two that I think are particularly important – SketchFlow Rapid Prototyping, and Blend Behaviors. I’ll cover SketchFlow in some depth in a future post. In this post I’m going to talk about Blend behaviors and how they can be used to extend Helix, my prototype Silverlight navigation framework.

What Are Behaviors?

Behaviors are objects that encapsulate some form of interactive behavior. Blend allows them to be easily 'attached’ to visual elements in the UI, via drag-drop or declaratively in XAML. They enable developers or designers to rapidly add rich interactivity to the UI without having to write code.

Blend 3 ships with a number of behaviors (shown left) that allow you to easily animate an element, change it’s visual state, start/stop a storyboard, play sounds, etc.

However, the key thing is that Blend allows you to create new behaviors of your very own. And not only that, but when you do they will automatically show up in the Blend toolbox ready for use by a developer or a UI designer.

There is also an Expression Gallery here dedicated to community developed behaviors, so if you develop a particularly cool behavior you can readily share it with other Blend users.

Behaviors – Think XAML Extension Methods!

The implementation details and concepts behind Blend behaviors are pretty simple. They leverage the simple but powerful ‘attached property’ mechanism in WPF and Silverlight. Instead of attaching a simple value though (like Grid.Row=”2”) you’re attaching an object that encapsulates behavior. Such objects are sometimes called Attached Behaviors. They provide an elegant way to extend existing controls without having to modify the control’s code or it’s UI template. I like to think of attached behaviors as the XAML equivalent of extension methods in C#.

Developers have been using attached behaviors for quite a while now as a way of extending Silverlight and WPF. In fact, they are pretty much the only way that you can extend Silverlight, since it lacks a number of other key extensibility mechanisms (such as custom markup extensions). As such, they’ve proven to be a very useful way to add missing functionality to Silverlight.

For example, since Silverlight controls do not (yet) inherently support commanding, we used this technique in Prism for wiring up button-derived controls to commands on the ViewModel:

<Button prism:Click.Command="{Binding ViewOrdersCommand}" />

I also used this technique in Helix to implement CollectionView support (now thankfully redundant since it’s supported in Silverlight 3.0).

Both Prism and Helix provide base classes that allow you to more easily create attached behaviors, and there are a number of other third party behavior frameworks that you can use too. But now that we have the Blend Behaviors Framework, we can hopefully all standardize on a single framework.

Triggers, Actions and Behaviors

Blend behaviors actually come in two main flavors – Actions and what I’ll call Full Behaviors.

Actions are simple behaviors that encapsulate an action (believe it or not) that are associated with a trigger. You can use an action and trigger pair to make something happen as the result of an event fired by the parent control. You can, for example, change a property value, control a storyboard, play a sound, or cause a control to move to a particular visual state as the result of a Click, MouseLeave, MouseEnter, MouseLeftButtonDown event, or any other event that the parent control fires.

Here’s a simple example – when the user moves the mouse over the image, the opacity property is changed to 0.5:

<Image Source="MyImage.png">

  <i:Interaction.Triggers>

      <i:EventTrigger EventName="MouseEnter">

          <ic:ChangePropertyAction PropertyName="Opacity" Value="0.5"/>

      </i:EventTrigger>

  </i:Interaction.Triggers>

</Image>

You could of course choose a different event to trigger the action, or choose a different property to change. Blend makes it very easy to drag an action onto a control and to configure it to do what you want.

Some actions operate solely on the parent control that the trigger is connected to. Some actions can operate on a control other than the parent. These actions are called Targeted Actions. If no target is explicitly specified, the target defaults to the parent control.

You’ll notice that the EventTrigger is added to a triggers collection. That means you can add as many triggers to a control as you like. Other types of triggers are possible too, not just ones that are associated with the target control’s events. For example, you can imagine using mouse/stylus gestures as triggers, etc.

Full behaviors are useful for encapsulating more complex interactive behavior that aren’t necessarily associated with a single trigger. The following example uses one of the coolest behaviors that Blend provides – the MouseDragElementBehavior. By simply attaching this behavior to a control, you can allow the user to drag it around in the UI!

<Image Source="MyImage.png">

    <i:Interaction.Behaviors>

        <il:MouseDragElementBehavior ConstrainToParentBounds="True"/>

    </i:Interaction.Behaviors>

</Image>

Again, you’ll notice that it gets added to a behavior collection, so you can have multiple behaviors on a single control.

Blend provides an assembly, System.Windows.Interactivity, that contains a number of base classes that you can use to define your own triggers, actions and behaviors. Simply add a reference to this assembly to your project (you’ll find it in the ‘C:\Program Files\Microsoft SDKs\Expression\Blend 3\Interactivity\Libraries\Silverlight|WPF’ directory or thereabouts) and away you go. Any triggers, actions, or behaviors that you define will automatically be available in the Blend toolbox. Let’s see this in action…

A Custom Action

Some of you may have been following my series of posts on the Helix navigation framework for Silverlight. If so, you’ll know that Helix provides a NavigateLink control that you can use within a page to link to another page that the user can navigate to. The NavigateLink control derives from Silverlight’s HyperlinkButton control. It’s a very simple control – the only thing is really does is to fire a navigate event up the visual tree so that it can be handled by a Frame control which then manages the actual navigation.

But what if you don’t want to use a NavigateLink button control to initiate navigation? Say you want to navigate using a different control, like an Image or a ListBox, or in response to a different event than Click, like MouseEnter/Leave or SelectionChanged? Well, now you can with the HelixNavigateAction!

The HelixNavigateAction class is pretty simple. It derives from the Blend TargetedTriggerAction class – the target in this case is a Frame so you can initiate navigation on a specific frame. It defines two dependency properties, NavigateUri and NavigationParameter. The overridden Invoke method is the only interesting part of this class and is shown below.

protected override void Invoke( object parameter )

    Uri navigationUri = this.NavigateUri;

    // Navigate to the specified Uri.

    if ( this.NavigateUri != null )

        // See if we have to format the navigation Uri with

        // any parameters.

...

        // See if the target frame has been specified explicitly.

        // If not, bubble a request navigate event through the visual tree.

        Frame frame = this.Target as Frame;

        if ( frame != null )

            frame.Navigate( navigationUri );

        else

            // Bubble the RequestNavigate event to the nearest

            // parent Frame.

            UIElement parent = this.AssociatedObject as UIElement;

            parent.RaiseEvent(

              Microsoft.Samples.Helix.Controls.Frame.RequestNavigateEvent,

              new RequestNavigateEventArgs( navigationUri, TargetName ) );

As you can see, we first check to see if a target Frame has been specified. If it has, we call the Navigate method on it directly. If not, then we raise a RequestNavigate event which will bubble up through the visual tree until a containing Frame control is found. That’s pretty much it. In the next section we’ll see how we can use the HelixNavigateAction class in Blend.

While creating actions in Blend is fairly straightforward, there are a couple of wrinkles to be aware of…

If you look closely at the classes provided in the System.Windows.Interactivity namespace, you’ll see that there are two main action classes – TriggerAction<T> and TargetedTriggerAction<T>. Both ultimately derive from the TriggerAction base class. Now you’d probably think that the generic parameter <T> in each of these classes would specify the same kind of type.

Well, it seems that the <T> in TriggerAction<T> specifies the type of Associated (parent) control, but the <T> in TargetedTriggerAction<T> specifies the type of the Target control. For a TargetedTriggerAction, to constrain the type of the parent control, you have to add a TypeContstraint attribute to the class:

[TypeConstraint( typeof( UIElement ) )]

Not sure why they did it like this… This design seems a little weird to me. I would have thought something like TargetedTriggerAction<A,T> would have worked better, then you could specify the types of the Associated and Target controls in the same consistent way…

The other thing to be aware of is that, if a Target value is not explicitly defined for an Action, the Target property will be set to the Associated parent control instance. This means that the type of the Target has to be assignable to the type of the Associated control. For example, we’d ideally like our HelixNavigateAction class to target Frame controls, but be associated with any type of control. Something like this:

[TypeConstraint( typeof( UIElement ) )]  <- Type of Associated Control

public class HelixNavigateAction :

        TargetedTriggerAction<Frame> <- Type of Target Control

This won’t work unfortunately since if a Target is not explicitly specified, it will be assigned the Associated control (which is probably not a Frame) so an InvalidOperation exception will be thrown at runtime. Again, not sure why they did it like this. I would have thought that leaving Target as null if it hadn’t been explicitly specified would have worked better. Yes, you’d have to check for null and then perform the action on the Associated object (maybe) but you’d have much more control and flexibility… Ho hum…

HelixNavigateAction In Action

So with our newly minted HelixNavigateAction class all compiled, let’s put it through it’s paces in Blend. You can download the sample project (including the latest version of Helix) here.

We’ll start with a simple app with main screen that contains a frame (the big area on the left) and four headline controls (on the right).

We’re going to use the HelixNavigateAction to navigate the frame to various pages as the user clicks on the headline controls on the right. If you click on the Assets tab and then on Behaviors, you will see a list of Behaviors and Actions that you can use. You’ll notice that the HelixNavigateAction is already there for us!

Simply drag the HelixNavigateAction over and drop it one of the headline controls on the right hand side of the main screen. You see the action get added to the object tree and the property grid will show various trigger and action properties. Let’s setup the trigger first by choosing the MouseLeftButtonDown event in the EventName dropdown. Next, we’ll set the target. For this we can use the rather nifty target picker! You just click on the round target icon and then click on the Frame and hey presto! the TargetName property is filled in:

Finally, we just have to specify the Uri to navigate to. For that we simply use the dropdown on the NavigateUri property and select whichever page we want to navigate to:

Repeat for the other three controls and that’s it, we’re all done! For grins, change the trigger event to MouseEnter to get a ‘hot-spot’ navigation effect. You can run the completed app here.

With Blend and the Blend Behaviors Framework we have a pretty powerful and flexible way to create re-usable components that encapsulate interactive behavior and a way to use them to snap together an application very rapidly.

I’ve only really scratched the surface here. There are plenty of other cool and powerful things that we can do with behaviors. Also, it may be that we can leverage this framework in the next release of Prism, and thereby replace our implementation in favor of the Blend implementation. Not only will this reduce the amount of code in Prism, it will also allow us to leverage the built-in design-time support that Blend provides…

Helix

I made a few small changes to the Helix framework to support the use of Blend Behaviors. I also updated the samples for Silverlight 3.0. You can download the latest version here (version 0.31).

Blend Behavior Resources

You might find the following resources useful as you explore Blend and the Blend Behaviors Framework:

The Expression Blend home page: http://expression.microsoft.com/en-us/cc136530.aspx
Expression Behavior Gallery: http://gallery.expression.microsoft.com/en-us/site/search?f%5B0%5D.Type=Tag&f%5B0%5D.Value=Behavior
Christian Schormann’s posts on Behaviors: http://electricbeach.org/?cat=30
Kirupa Chinnathambi’s posts on Behaviors: http://blog.kirupa.com/?cat=18

ViewModel and Dependency Injection

dphill — Mon, 18 May 2009 22:28:23 GMT

In my last post – Silverlight Navigation Part 3 – I outlined a mechanism whereby you could navigate to a View and have the application create and wire up the associated ViewModel automatically. I also showed the inverse of this, where you could navigate to a ViewModel and have the application automatically create and wire up the associated View automatically.

Whether you prefer the View-First or the ViewModel-First approach, the essential feature that really supports the ViewModel pattern is that the system should be able to create a ViewModel for a View (or vice versa) automatically. Otherwise, the burden falls to the developer to do this in code, which can result in a complicated architecture that’s either inflexible or difficult to understand and maintain.

Let’s say, for example, that you have adopted a View-First approach. Now, you could just have some code in your application (say, in a controller component or event handler somewhere) that simply creates the required View and it’s associated ViewModel and wires them together like this:

public ShowCustomer()

    CustomerView view = new CustomerView();

    CustomerViewModel viewModel = new CustomerViewModel();

    view.DataContext = viewModel;

    myContentControl.Content = view;

You can use this approach with a ViewModel-First approach too. Another simple approach is to just get the View to create its own ViewModel, either in its constructor:

public partial class CustomerView : UserControl

    public CustomerView()

        InitializeComponent();

        this.DataContext = new CustomerViewModel();

or via XAML:

<UserControl.DataContext>

    <CustomerViewModel />

</UserControl.DataContext>

All three of these approaches work great, except that they hard code your application to use specific View and ViewModel types. This may very well not be an issue for you, and if it isn’t, I say go for it!

However, there are times when you’ll want to have the View and the ViewModel types more loosely coupled. An example might be when you want to decide at run-time which View to display for a particular ViewModel based on, say, the user’s role, chosen UI theme, screen size, or even the type of device that the user is using(!). So, while the approaches above are simple, they are relatively inflexible.

Dependency Injection To The Rescue?

It is at this point that the Dependency Injection folks will start to gesticulate wildly and remind us that this is exactly the situation in which DI excels. Remember that with DI, if you have a dependency between one class and another, the system (i.e. the DI container) can automatically fulfill that dependency dynamically at run-time for you. This allows the classes to be more loosely coupled and removes the need for you to manage the creation of dependent classes yourself. Let’s see how this works…

Say we have a class ‘A’ that depends on (i.e. has a reference to) a class ‘B’. Typical DI containers (including Unity) require that we express the dependency between A and B using a type – typically (but not necessarily) an intermediate interface type, say IB – and that we define a constructor on A that takes a reference to that type. We then register our implementation of the intermediate interface type with the container – so that it knows that whenever anybody wants an implementation of IB it will create an instance of B.

So, when we want an instance of class A, we just ask the container to create one for us. It spots that class A requires a reference to an IB implementation, so it goes and creates a B for us automatically and passes a reference to it to A’s constructor. The container manages the creation of dependent classes for us!

It is of course true that in many situations DI is a good solution for this kind of problem. I think though, that for the ViewModel scenario DI is not ideal. To illustrate why, let’s see how DI typically works in View-First and ViewModel-First scenarios…

The Perils of IViewModel

In our View-First example above, we have a View that wants a reference to (depends on) a ViewModel, so we’d first register an implementation of our ViewModel with the container:

_container.RegisterType<ICustomerViewModel, CustomerViewModel>();

and we’d design the View so that it gets a reference to the ViewModel implementation in its constructor:

public CustomerView( ICustomerViewModel viewModel )

    this.DataContex = viewModel;

Finally, we’d get the container to create an instance of the View. The container will automatically create an instance of the registered ViewModel type and pass a reference to it into the View’s constructor.

CustomerView view = _container.Resolve<CustomerView>();

Ok this works, but I think there are a number of problems with this approach:

To create the View we have to use the DI container. We can’t just create the View using ‘new’ and we can’t create it declaratively via XAML (since that will use the default constructor which won’t pass in a reference to the required ViewModel). In other words, we have to have a controller or event handler or some code somewhere that creates the View via the container by calling Resolve.
The UI designer (even if the UI designer is really a developer) should not have to write code in the View just to make it work. If there is some complicated UI behavior that can’t be done declaratively, then code may be required, but this should be a special case and not required every time just to get stuff wired up and working. Even implementing the simple constructor above takes some explanation and can be easily forgotten or incorrectly implemented.
We have defined a ‘marker’ interface type that we don’t really need – i.e. the interface has no properties or methods, we’re just using it as a marker. Yes, we could define some properties and method on it, but the View should not be programmatically calling into the ViewModel. Remember, UI designers should not have to write any code. All interactions between View and ViewModel should be done via bindings and attached behaviors so that the View is just a loosely coupled observer of the ViewModel.

The Evils of IView

So that’s Dependency Injection in a View-First world. What about a ViewModel-First world? Well, things are no better here either. Similar to the process outlined above, we’d probably define an IView interface; register an implementation of it with the container; define a constructor on the ViewModel that accepts an IView reference; then create an instance of the ViewModel using the container:

_container.RegisterType<ICustomerView, CustomerView>();

...

public CustomerViewModel( ICustomerView view )

    ((FrameworkElement)view).DataContext = this;

...

CustomerViewModel viewModel = _container.Resolve<CustomerViewModel>();

Again, a couple of problems with this approach:

Again, we can’t create a View declaratively using XAML – the container will create the View as a result of creating an instance of the ViewModel class – so we’d have to have a controller or event handler or some code somewhere to kick things off.
We’d have a marker interface that we’d don’t really need and that won’t define any properties or methods – the ViewModel should not be programmatically calling into a View.
The UI designer would have to implement an interface on the View each and every time they create one. It’s not terribly complicated, but the UI designer should not be required to write any code except for advanced scenarios.
The ViewModel-First approach is actually slightly worse that the View-First approach because of the nasty cast in the constructor. This is required in order to set the view’s data context to the ViewModel.

Wouldn’t It Be Nice If…

In my last post on navigation, I showed a couple of different approaches to the problem of conjuring up a View for a ViewModel (or vice versa) without using a Dependency Injection approach.

For View-First, instead of using DI and defining interfaces and constructors, I just used an attached property on the View to specify the type name of the ViewModel (ViewModel.TypeName) and the system automatically constructed the ViewModel for me and wired it up to the View’s DataContext.
Going the other way (ViewModel-First) , I just used a naming convention to infer the name of the View from the ViewModel’s type name, created an instance of that View and set it’s DataContext.

Neither of these approaches are ideal though, so I got to thinking what an ideal approach might look like… The key is that we need a simple way of expressing the relationship between the View and the ViewModel types so that the system can just make the right things happen!

If you’re familiar with DataTemplates in WPF, you know that it’s possible to define a DataTemplate (somewhere in the application’s resources) for a particular (non UI) type. Whenever the system has to display an object of that type, the DataTemplate is automatically used to visually represent it. Under the covers, the system creates an instance of the DataTemplate, sets its DataContext to the object that it represents, and then displays it in the UI. Silverlight does not yet support implicit data templating – you have to specify the DataTemplate explicitly for each control – but the mechanism is very similar.

I think this is close to what we want…

I think of DataTemplates simply as “Thin Views” – i.e. purely declarative Views with no code behind. They are very useful, but sometimes you just need to have some code in the View (for complex visual behavior that can’t be done declaratively). So, if the system could be extended to include Views that could have code behind, it would all fit together in a nice, simple, consistent model. It could look something like this…

We define a View as usual and simply declare that it is associated with a ViewModel data type:

<UserControl x:Class="MySample.CustomerView"

             DataType="{x:Type MySample.CustomerViewModel}"

For the ViewModel-First approach, we simple create (or navigate to) an instance of the ViewModel and display it. For example,

MyContentControl.Content = new CustomerViewModel();

The system would then step in and create an instance of the View that corresponds to this type and would wire up the DataContext for us – just like the system does today with DataTemplates!!!

Similarly, for View-First, where we simply create (or navigate to) a View, the system would automatically create an instance of the associated ViewModel type for us and wire up the DataContext. There would likely be another property to control this behavior.

I think this approach has a number of benefits:

The system carries the burden of finding and creating corresponding Views and ViewModels, making our application code much, much simpler. And simpler means that it’s faster to write, easier to debug, and easier to unit test!
It gives us a single consistent model that works for Views with and without code behind.
It works declaratively as well as programmatically giving us a lot of freedom to create Views or ViewModels in code or in XAML as desired. It works great with navigation too.
It allows Views to express a dependency on a particular ViewModel, while allowing ViewModels to remain completely View agnostic. This opens up a whole host of interesting design-time tooling possibilities – like you get with DataTemplates today – but with more explicit support for the ViewModel pattern. For example, you can imagine that the UI designers can provide intelli-sense or drag & drop support for binding expressions and behaviors (because the design-time system can determine the ViewModel’s commands, notifications and properties).

You’ll have noticed that we’re not using an intermediate interface type to loosely couple the View and ViewModel. The approach could be extended to support that though, for example by using the upcoming Managed Extensibility Framework (MEF), or by building in some form of simple Dependency Injection mechanism into the XAML loader system.

Until I prototype this approach more fully, it’s not clear whether it will really work as well as expected. Also, it’s not clear at this stage when (or if) we could expect it this approach to be implemented in the platform.

We can but dream though…

Silverlight Navigation Part 3

dphill — Tue, 28 Apr 2009 23:45:26 GMT

Welcome to the third post in my series on navigation in Silverlight! The goal of this series of posts is to provide a simple to use framework (called Helix) for building Silverlight applications that are based on a flexible navigation mechanism and the ViewModel separated presentation pattern. This post is long and was a tough one to write (which is partly why it took so long to complete!) but this post takes us much closer to our goal.

If you’ve been reading this series from the beginning, you’ll have noticed that we’re taking something of an agile approach to building Helix. You can think of each post in this series as an iteration. And like all good agile projects, we’re not afraid of a bit of refactoring, or of adding or significantly altering features as we tackle new scenarios. So in the latest version of Helix you’ll find some changes compared the version in part 2.

Some of these changes are bug fixes, but most are new features or extensions to existing features to support the ViewModel pattern alongside navigation. You’ll also find more samples and unit tests in this drop. There is a summary of the main changes and new features at the end of this post. You can download the latest release from here and you can run all of the latest samples from here.

The Story So Far…

Before we get into any details, let’s quickly review what we’ve covered in previous posts…

In the first post in the series, I introduced the Helix Frame and NavigationLink controls and showed how they could be used together with a simple Journal to implement a simple navigation mechanism between pages in a Silverlight 2.0 application.

In the second post in the series, I introduced the Route, NavigationHandler and NavigationController classes and demonstrated how they can be used to implement navigation between pages based on parameterized navigation links. That post also showed two ways of passing parameters via the navigation link to the target page, so that the page can be initialized or have it's context set appropriately.

One way was to use the NavigationPageController class which passes all of the navigation parameters to the target page's OnNavigate method (through the INavigationPage interface). The other way was to use the PageActionController class which invokes a page action method on the target page by mapping the navigation parameters to the method's name and it's parameters.

Both of these approaches created an instance of the target page and then passed the navigation parameters directly to it. As noted in the second post, this is clearly not ideal since it means that the page will then contain application logic as well as UI – not good for a lot of reasons!!!

Separated presentation patterns like the ViewModel pattern help to keep the UI and application logic cleanly separated. I described the ViewModel pattern in a previous post, but to recap, the ViewModel pattern separates UI and presentation logic into View and ViewModel classes, and uses data binding and commands to communicate between them. In this post, I provided an implementation of a generic ViewModel for handling collections, imaginatively called CollectionViewModel. In this post, I described two strategies in which the View and the ViewModel can get created and linked up. In View-First composition, the view is logically created first. In Presenter-First composition, the presenter (the ViewModel is our case) is logically created first.

These three additional posts can be considered parts 2a, 2b and 2c of this series, so please check them out if you haven't already done so. We’ll be building on the concepts and features they describe in this post.

Ok, that’s the background information out of the way. Let’s get started extending the Helix navigation framework so that it works alongside the ViewModel separated presentation pattern…

The Challenge: Mixing ViewModels and Navigation

One of the challenges with any separated presentation pattern is that you have to have some way of creating, hooking up and managing the additional components that are involved. In our preferred ViewModel pattern these additional components are principally Views, ViewModels and Models.

Now, if your application is fairly static, it’s fairly straightforward to create and hook up these components. But if your application is more dynamic (for example, when the UI changes constantly because the user is navigating around within the application!) then things are not quite so simple. As well as creating and hooking up these components during navigation, we also have to figure out how the other parts of the application are going to interact and communicate with them.

In my experience, this issue – the handling of Views, ViewModels and Models in a dynamic application that includes navigation – is the one that causes the most confusion and pain for folks building real-world applications using the ViewModel pattern. It is this very issue that we’re going to tackle in this post…

Choosing A Navigation Scheme

Before we get into the details on the integration of the ViewModel pattern into the Helix navigation framework, we first have to think about the different ways in which we can structure our application so we can and navigate around within it.

Helix essentially allows you to design a navigation scheme for your application by allowing you to decide how the various elements in your application are linked together by parameterized Uri's. When you define the format of the navigation links in your application, you are designing the way in which the user will navigate through your application to access its functionality and content by identifying the main navigational elements in your application and identifying which parameters are passed to them. At a high level, there are two basic navigation schemes to choose from.

Perhaps the simplest navigation scheme is one where the application's navigational links refer directly to the application's visual elements. Using this scheme means that we'll link the application together using Uri's that refer to pages or controls within the application and allow the user to navigate between them. This is the navigation scheme that we used in the last two posts of the series. I think this type of navigation scheme tends to work great for content-centric applications – i.e. when the user expects to be primarily navigating through content. Blog readers, news readers, and media sharing apps are good examples of this type of application.

With Helix you are not limited to using simple page-based navigation schemes. You can link your application together in other interesting ways. In particular, you can structure your application so that it's composed of tasks or actions that the user carries out. I call these types of applications task-centric applications.

Let's look at a simple example – an expense reporting application. In terms of tasks, the user can create, edit, submit, approve, reject, or archive expense reports, so we could structure our application so that the user naturally navigates between these tasks in sequences that are natural. For example, the user may start by creating a new expense report and then submit it for approval; then they may edit a draft expense report and save it for later submission; then they may review their approved expense reports and archive them away for safe keeping.

I think this type of navigation scheme is very interesting. It means for instance, that we can align our application’s navigational structure with the application's use-cases and the user’s tasks, rather than having to strictly follow the visual structure of the application. This means that we can more cleanly separate the visual structure of the application from its logical structure and work flow, which in turn means that we can more easily test the application, and have more flexibility when designing a fluid, animated UI for it. In addition, when we consider deep linking (in a future post) we'll see that the user, or other systems, very often will be exposed to the navigational structure of the application, so having a navigation scheme that’s independent of the visual structure can also be important for many other reasons.

At this point you might be asking: “Yes, but does it really matter what the navigational scheme for an application is since the user never sees it – they just click on links and the UI gets updated?”. This is of course true, up to a point. It’s not clear that one approach is superior to the other – I can see advantages and disadvantages with each – so we’ll explore both approaches to see what each feels like when building an application.

Whatever your choice of navigation scheme, content-centric or task-centric, the important thing is that you are comfortable with it and use it consistently throughout your application. Using multiple schemes within the same application can lead to user confusion and an application that’s difficult to maintain or extend. Choosing a navigational scheme that's natural for your application will help you build, test and extend it much more easily and will help to make it easier to use, so it’s important to design your navigation scheme wisely and to stick to it.

Ah, But What About The ViewModel?

Regardless of the navigation scheme, things get even more interesting when we introduce the ViewModels pattern into the navigational picture. Using the ViewModel pattern means that we'll have a component that encapsulates the UI (the View), and a component that encapsulates the presentation logic and state (the ViewModel). My post here describes the ViewModel pattern in some detail.

The View and the ViewModel have to get created and hooked up together and this can happen in one of two ways – the view is either logically created first followed by the ViewModel on which is depends, or the ViewModel is logically created first followed by the View on which it depends. I call these two mechanisms View-First or ViewModel-First composition respectively – see my post here for more details.

Now – and this is a key point – if you think about a content-centric navigation scheme as described above, you'll see that this maps very naturally to View-First composition! The user is logically navigating to a View so we construct the View first, followed by the ViewModel on which it depends and that provides a clean separation between UI and presentation logic.

On the other hand, with a task-centric navigation scheme, the user is logically navigating to a component that manages an activity or task. This component (as we'll see below) maps quite naturally to a ViewModel, so logically we're creating the ViewModel first, followed by the View on which it depends so that it can be visually represented in the UI. In other words, task-centric navigation maps naturally to ViewModel-First composition!

So, we can clearly identify two distinct navigational styles:

View-First Navigation – Where the user navigates between Views in a content-centric application,
ViewModel-First Navigation – Where the user navigates between ViewModels that represent tasks or activities within the application.

Interestingly, you can also see the correlation between content-centric navigation and view-first composition, and task-centric navigation and presenter-first composition, in ASP.NET web applications.

With traditional ASP.NET web applications, the application consists of a number of pages that are linked together by simple Uri's. In other words, the navigational structure of the application is based on visual elements linked together. With ASP.NET WebForms, the pages can be richly defined using server-side controls, client-side AJAX controls, and with MasterPages and so on, but the navigational structure is always based on pages and the ASP.NET runtime will create the pages as you navigate to them. You may optionally choose to separate the presentation or business logic from the UI by using an MVP pattern, but in this case, the Presenter will be constructed by the page itself.

On the other hand, using ASP.NET's MVC framework, we can define a navigational scheme that follows the logical structure of our application and that is independent of the visual pages within the application. By defining suitable navigation routes we will logically navigate to a controller component which then allows us to create a suitable view and hook it up to a data model component. We technically have controller-first composition, but hopefully you can see that this is the moral equivalent of constructing a ViewModel before the View.

In this latest drop of Helix, I’ve added support for both View-First navigation and ViewModel-First navigation by implementing a navigation controller for each. The rest of the Helix architecture remains essentially the same (though there are some new features and some fixes as detailed at the end of this post). Remember, you can always implement a custom controller if you want to change the implementation that’s described below.

Instead of walking through the implementation of these controllers, it’s probably more useful to walk through a sample application for each navigation style so you can see how they are both put together. In the examples below, I’m also using some of the new and improved features in Helix that are common to both styles of navigation.

Ok, enough theory, let’s see some code!

View-First Navigation

To illustrate View-First Navigation, I took the Order Entry sample application from the second post and converted it to use ViewModel pattern. You’ll remember that this sample was based on a navigation scheme where the links referred to the pages within the application, so it was relatively straightforward to keep that navigation scheme and introduce the ViewModel pattern into it. You can run the final application here. Let’s walk through the application so you can see how it all fits together…

The application consists of a number of Models, ViewModels and Views, plus a RootPage and an Application class. The RootPage is a simple page with a Frame control – as we navigate between pages, they will displayed here.

The application uses three model classes to represent the customer, sales order and the sales order line items. In this sample these are just simple classes with a number of properties. These are all defined in the Models folder.

The ViewModels for the application are defined in the ViewModels folder. The ViewModels implement a number of commands and properties that the Views can bind to. The application’s pages are all defined in the Views folder. None of the pages have any code behind; all of the UI is defined declaratively in XAML. The pages bind against the ViewModel’s commands and properties.

All of these classes are connected together at run-time through navigation. The navigation scheme for the application is defined in App.xaml. With the latest drop of Helix, we can define the navigation routes, and associated controller and default parameter values, as an application resource. This allows us to define the navigation scheme for our application declaratively without having to write any code.

<n:RouteTable x:Key="GlobalNavigationRoutes">

    <n:Route UriTemplate="/[PageName]">

        <n:Route.Controller>

            <c:PageController DefaultResourcePath="Views" />

        </n:Route.Controller>

    </n:Route>

    <n:Route UriTemplate="/[PageName]/[CustomerID]">

        <n:Route.Controller>

            <c:PageController DefaultResourcePath="Views" />

        </n:Route.Controller>

    </n:Route>

    <n:Route UriTemplate="/[PageName]/[CustomerID]/[SalesOrderID]">

        <n:Route.Controller>

            <c:PageController DefaultResourcePath="Views" />

        </n:Route.Controller>

    </n:Route>

</n:RouteTable>

In this application we have three navigation routes. The first route defines no parameters just the page name, but the second and third routes add CustomerID and SalesOrderID parameters. Each route uses a PageController. The DefaultResourcePath tells the controller where to look in the application for the pages that we will navigate to.

The bulk of the application’s logic is defined in the ViewModel classes. The ViewModels implement a number of commands and properties and expose them to the UI for binding. Helix includes a number of features to help with View to ViewModel binding.

Simple properties exposed by the ViewModel are easy to bind to. In the case where the underlying data managed by the ViewModel is a collection (for example, a collection of customers), the ViewModel creates a CollectionViewModel class to wrap it. This class manages currency, selection and sorting of the underlying collection. The View and CollectionViewModel are kept in sync using the SynchronizeCollectionView attached behavior like this:

<ListBox ItemsSource="{Binding Customers}"

     h:SelectionChanged.SynchronizeCollectionView="{Binding Customers}">

My post here on CollectionViewModel describes in detail how this attached behavior works. I have now rolled the CollectionViewModel and the SynchronizeCollectionView attached behavior classes into Helix so everything is in one place.

The ViewModels also implement commands that the View can bind to. Commands are implemented using the Prism DelegateCommand class – see here for more information on Prism and Delegate Command pattern. Commands can be bound to UI elements using the Prism Command attached behavior. Command parameters can also be defined using the CommandParameter attached behavior.

<Button Content="Edit"

    prism:Click.Command="{Binding ViewOrdersCommand}"

    prism:Click.CommandParameter="{Binding Customers.CurrentItem}" />

In the example above, we’re binding the Edit button to the ViewOrders command and passing in the currently selected customer as a command parameter. When the user clicks the button, the command’s method will be invoked with the current customer as a parameter. If the Edit command is not available, the button is disabled automatically.

Many of the commands in the application result in a navigation. Commands which result in navigation are typically implemented like this:

private void ViewOrders( Customer customer )

    // Navigate to the Orders page.

    Uri navUri = new Uri( string.Format( "/Orders/{0}", customer.CustomerID ),

                          UriKind.Relative );

    _navigationContext.Target.RequestNavigate( navUri );

The Uri above is formatted in accordance with the navigation scheme that we defined in App.xaml. The Uri can include parameters such as the customer ID and these are passed to the target ViewModel when it’s created. This makes it very easy to pass parameters around during navigation. Since we have a View-First navigation application, we could also use the Helix NavigationLink control and navigate directly from the page.

The navigation context you can see above is passed to the ViewModel by the framework when it is first constructed as a result of navigation. You can use the navigation context class to get access to the navigation parameters, or to ask the navigation target to navigate to another Uri as shown above. The NavigationContext class is discussed in more detail below.

There are just a couple of final things that we need in order to stitch everything together. Since we’re using a View-First navigation controller, navigation Uris, such as the one above, specify the name of the page to navigate to. In the example above, we’re navigating to the Orders.xaml page in the Views folder. So far so good, but how does the framework know which ViewModel to create for this view?

There are a number of ways to solve this problem. Ultimately we need to know the Type of the ViewModel class so we can instantiate it. One way to get this type is to infer it from the type of the View – so, for example, a view with a type name of ‘MyApp.MyView’ would infer a ViewModel of type say ‘MyApp.MyViewModel’. This would work but means that we would have to know about the naming convention and the relevant namespaces and we would have to follow both carefully when creating our ViewModel classes.

Another approach, and the one that is implemented in this sample application, is to allow the View to explicitly specify the type of the ViewModel it was designed for. To do that we just use a simple attached property. The Customers page, for example, specifies that it needs an instance of the CustomersViewModel class like this:

<NavigationPage
  x:Class="Microsoft.Samples.Helix.OrderEntrySample.CustomersPage"
  ...
  ViewModel.TypeName=
    "Microsoft.Samples.Helix.OrderEntrySample.ViewModels.CustomersViewModel">

You can imagine some day in the far flung future, when the tooling folks finally embrace the notion of separated presentation patterns, that the ViewModel’s type could be automatically specified by the tool when the user is designing the view – maybe even as a proper Type parameter making the View a generic type, for example MyView<ViewModelType>. We can only hope that that day will come soon…

In any case, when the framework creates the View it checks to see if there is a ViewModel specified, and if so, it instantiates the ViewModel and sets it as the View’s DataContext. All of this is handled by the PageController which is described in more detail below.

The last piece of the puzzle is the navigation context. Once the View and ViewModel have been created and hooked up, the controller passes in the navigation context which contains the navigation parameters and a whole bunch of other stuff. The ViewModel (or the View) can opt to receive the navigation context by implementing the INavigationAware interface, which consists of a single method OnNavigate:

#region INavigationAware Members

public void OnNavigate( NavigationContext context )

    // Store the navigation context for later.

    _navigationContext = context;

...

#endregion

The ViewModel can then retrieve the parameters it’s interested and retrieve the relevant data to initialize itself.

The PageController Class Dissected

The View-First application described above uses the PageController class to handle navigation. This controller does all of the heavy lifting and stitches everything together. It carries out four steps in sequence:

The first step is to create the View. The View’s name is specified as a parameter as part of the navigation Uri, as defined in the navigation routes in App.xaml. The View is created by loading the resource, prefixed with the DefaultResourcePath if one is specified.
The next step is to create the ViewModel. The ViewModel's type is specified using an attached property value on the View. If the View doesn’t specify a ViewModel type, this step is skipped.
If a ViewModel has been created, the next step is to set the View’s DataContext to the it. This allows the View to binding to the ViewModels properties and commands.
The final step is to set the navigation context on the View or ViewModel.

The last step probably needs some explanation. In part 2 of this series you may recall that we passed the navigation parameters to the target View using the INavigationPage interface. Now that we have ViewModel support, we probably don’t want to pass the navigation parameters to the page; we want to pass them to the ViewModel instead. In the latest drop of Helix, I have added a new interface INavigationAware that can be implemented by a View or a ViewModel (or both). The PageController checks to see if either the View or the ViewModel implements this interface and if so, calls the OnNavigate method, passing in the NavigationContext.

NavigationContext is a new class. It provides a single object from which to retrieve all of the information about the current navigation operation, including the navigation parameters, mode, Uri and target, etc. Most of the ViewModels in the sample application store a reference to the NavigationContext to use for initiating further navigation operations later on and for retrieving the parameters that they require.

The implementation of the PageController class described here is pretty simple. The strategy it implements is the one I settled on during my investigations, but you can easily change the implementation to suit your needs. For example, you can change the way in which the View or ViewModel gets created, or they way in which they get hooked-up, to whatever strategy you prefer. The beauty of the Helix framework is that you can make these changes in a single place without having to make multiple changes throughout the entire application!

ViewModel-First Navigation

OK, so much for View-First navigation. Let’s see what ViewModel-First navigation looks like…

To illustrate ViewModel-First navigation, I implemented a sample expense reporting application. You can run the application here. As described above, this application provides a number of tasks that the user can carry out. Each task will be rendered visually, so the user will experience these states through the UI, but to a large extent the tasks exist independently of how they are rendered.

The following diagram illustrates the tasks and the commands that lead to the transitions (navigation!) between the tasks. From the View Expense Reports task, for example, the user can create, edit, review, submit or archive an expense report; from the Edit Expense Report task the user can save the expense report and the application moves back to the View Expense Reports task.

The structure of the project is similar to the Order Entry sample described above. It consists of three folders that contain the application’s Models, ViewModels and Views, a root page and an application class.

The essential difference between this application and the Order Entry application described above is that navigation occurs between ViewModels. Each ViewModel represents a task so the bulk of the application logic is defined in the ViewModels. Each ViewModel implements properties and commands similar to those described above.

The ViewModel folder also contains a couple of ViewModel helper classes that perform data formatting for expense amounts and dates. These classes aren’t ViewModels per se, but they are used by the Views to help them render the data correctly.

There is a corresponding View for each ViewModel, defined in the Views folder. Again, the views contain no code behind.

Ok, let’s see how all of this fits together. First, the application’s navigation scheme is defined in App.xaml:

<RouteTable x:Key="GlobalNavigationRoutes">

    <Route UriTemplate="/[ViewModelTypeName]/[ExpenseID]">

        <Route.Controller>

            <ViewModelController DefaultResourcePath="Views"

                DefaultNamespace="Microsoft.Samples.Helix.ExpenseSample.ViewModels"/>

        </Route.Controller>

        <Route.Defaults>

            <NavigationParameter ParameterName="ExpenseID" ParameterValue="-1" />

        </Route.Defaults>

    </Route>

</RouteTable>

This application defines a single route that has two parameters – the ViewModel type name, and the expense report ID. A default value for the expense report ID is specified, so the navigational Uri’s don’t necessarily have to specify it. This route uses the ViewModelController navigation controller class. This is the class that coordinates how the ViewModels & Views get created, hooked-up, and initialized with the navigation context.

The ViewModelController has two properties – DefaultResourcePath, which tells it where to look for Views, and DefaultNamespace, which specifies the default namespace for the ViewModel classes. The operation of this controller class is described below, but essentially it works by creating a ViewModel then a suitable View for it, hooks them up via the View’s DataContext and then sets the navigation context.

The interaction between the Views and the ViewModels is the same as described above and includes commands and the CollectionViewModel sync attached behavior. Navigation between tasks occurs as commands are invoked on the ViewModels. A typical implementation of a command looks like this:

private void CreateExpenseReport( ExpenseReport expenseReport )

    ExpenseReport newExpenseReport = _expenseReports.CreateNewExpenseReport();

    // Navigate to the Edit ViewModel.

    _navigationContext.Target.RequestNavigate( new Uri(

            string.Format( "/EditExpenseReport/{0}", newExpenseReport.ExpenseID ),

                           UriKind.Relative ) );

The format of the Uri is as defined in the navigation route in App.xaml. In the example above, we’re passing an expense report ID as a parameter to the target EditExpenseReport ViewModel. When that ViewModel is instantiated, the parameter will be passed in as part of the navigation context and the ViewModel can retrieve the corresponding expense report. In this way, we can control not only what gets instantiated during navigation, but also how parameters flow around the system. This really simplifies how applications like this are put together…

The ViewModelController Class Dissected

Hopefully you won’t be surprised to learn that the ViewModelController creates the ViewModel first and then creates a suitable View for it. The sequence goes like this:

In the first step, the ViewModel is instantiated using the ViewModelTypeName navigation parameter, prefixed with the DefaultNamespace if one is specified. So for a ViewModel type name of ‘EditExpenseReport’, the type ‘Microsoft.Samples.Helix.ExpenseSample.ViewModels.EditExpenseReport’ will be instantiated.
The next step is to create a suitable View. The details of this step are described below. If a View can’t be instantiated, an exception is thrown.
The next step is to set the View’s DataContext to the ViewModel. This allows the View to binding to the ViewModels properties and commands.
The final step is to set the navigation context on the View or ViewModel.

In the View-First strategy described above we had the challenge of figuring out which ViewModel to instantiate for a given View. In ViewModel-First navigation we have the opposite problem – given a ViewModel, we have to decide which View to instantiate for it.

The current implementation takes a simple approach – we just append the ViewModel’s short type name with ‘View’ and load the corresponding View resource. So for the ‘EditExpenseReport’ ViewModel, we’d load the View ‘EditExpenseReportView’ located in the Views folder. This was an experiment to see how a naming-convention based approach would work.

There are other ways to solve this problem, but for the purposes of this sample, it works pretty well. You can always implement an alternate strategy in a custom controller class if you prefer a different way to create and hook-up the ViewModel or View.

End of Part 3

Well, that was a long post wasn’t it? We covered a lot of ground though. Since we’re building Helix from the ground up there are a lot of details to grok, and just like sausages and laws, it’s not always pretty seeing how things are made. The final framework, though, should be drop-dead simple to use – that’s the goal anyway!

We’ve been experimenting with alternate approaches to discover their advantages and disadvantages and to see which one might work as a default approach that will work for most applications. We’ve essentially identified two broad approaches that have potential and we can now build applications with a View-First navigational style, or with a ViewModel-First navigational style.

Which approach you use depends on your application and which approach feels most natural to you. The implementations described here work pretty well for both approaches but there are few things that need some improvement. The nice thing about Helix, though, is that it’s simple to implement alternate strategies or to tweak the behavior of the navigation scheme in an application. With a few changes here and there we can customize navigation without having to rewrite big chunks of our application.

Personally, I believe the ViewModel-First approach has a lot of advantages over View-First approach, but it takes some getting used to. The example above doesn’t really highlight the advantages of this approach in terms of testability and UI flexibility. I’ll try and focus on those in the next post in the series, as well as deep linking. I promise that you won’t have to wait as long for that post…

On another note, whatever approach we choose, there is always the ‘tooling problem’. In other words, what would the ideal tooling experience be like for building applications based on both a separated presentation pattern and a flexible navigation system? It’s not an easy question to answer. I have some ideas but they will have to wait for a future post too…

As always, please let me know what you think of Helix – what you like or don’t like, etc. If you have any feedback on Helix, please drop me a line.

oO------Oo

Helix 0.3: Changes and New Features

A quick summary of the main changes and new features in this drop of Helix:

Added support for global routes. Global routes are managed by the Navigation Manager and can be defined as an application-level resource in XAML. If not global routes are defined, a default global rout is added automatically. Frame-local routes can also be defined and are checked for a match first during navigation. If a match at the Frame level is not found, then the global routes are checked. This provides a lot of flexibility when implementing hierarchical navigation scenarios in an application.
Moved the page loader code to the static Navigation Manager class. Centralizing this code allows for multiple controller classes to take advantage of it (and allows for it’s ultimate replacement by the Silverlight framework itself if and when it supports the ability to load pages by resource name).
Removed the need to register the application’s main assembly with the Navigation Manager class. The Navigation Manager now searches all assemblies in the application manifest (except those beginning with System). This also the Navigation Manager to instantiate Views and ViewModels without the developer having to specify which assembly they are defined in, which in turn allows for easier integration between UI and non-UI application layering.
Default constructors added for Route and Journal classes. Using the default constructor for a Route object instantiates a default PageController instance. Similarly, using the Journal’s default constructor instantiates a default RouteNavigationHandler instance. These default constructors allow for simpler declarative setup in code or XAML.
NavigationParameter and related classes were also changed to support default construction and the ability to declaratively specify default values in Routes.
Refactored the regular expressions in the Route class to const strings to allow for easier customization. Also tidied up the regular expression for identifying fields in the navigation Uris. This allows you to more easily change which characters are allowed in navigation fields (e.g. you can now define fields that include period and dash, so you can use GUIDS for example).
Refactored all Controller and Journal classes into their own namespaces.
NavigationUIVisibility is now in the Helix Controls namespace.
Controller parameters – added the ability for a controller to specify its required parameters using an attribute. This allows the controller base class to automatically check incoming parameters to make sure that all required parameters have been provided. This simplifies error handling and the implementation of derived controller classes. This also allows for the associated Route object to check for a compatible controller when the Route is first registered.
Navigation Context – Added Navigation Context class which includes all of the information pertaining to the current navigation operation, including the navigation parameters, original Uri and the navigation target. This provides for a simple API, better extensibility and allows ViewModels to store a reference to their navigation context so they can initiate or initiate/cancel/redirect a navigation operation.
Added PageController and ViewModelController classes. Removed the NavigationPageController class (this functionality is now provided by the PageController class). The PageActionController class is now derived from the PageController class.
Added DefaultResourcePath property on PageController & ViewModelController to allow views to be loaded from a sub-folder in the project. The previous version of Helix required all pages to be defined at the project root level.
Added InitialUri dependency property on the Frame Control. This allows the Frame to navigate to the specified Uri when the Frame is first loaded, removing the need for code behind in the root page.
Added CollectionViewModel to Helix library. Also added a number of bug fixes in the Refresh and OnModelChanged method. The latter is required due to weird behavior with the Silverlight DataGrid control.
Added a unit test project with unit test for Routes, Navigation Manager, Page and ViewModel Controllers, CollectionViewModel, etc.
That’s all the changes I can remember…

A quick note on Silverlight 3.0 Beta: Helix and all of the associated samples are built for Silverlight 2.0. However, you should have no problem using Helix with the Silverlight 3.0 Beta. There are a few known issues in Silverlight 3.0 Beta to do with memory leaks but these probably won’t affect you too much and they’ve been fixed in later versions.

Mix 09!

dphill — Wed, 18 Mar 2009 20:35:42 GMT

Mix 09 starts today! There have been a number of key announcements made at Mix, especially concerning Silverlight 3.0 and Blend 3.0. If you are at all interested in Web and Silverlight development then be sure to check out the "Gu's" keynote highlights here.

The next releases of Silverlight and Blend have lots of interesting features. I'll cover them in detail in a future post, but one question that I'm sure is top of mind is how the new version of Silverlight relates to Prism and Helix.

Silverlight 3.0 provides a lot of new features that are nicely complementary to Prism. These new features help with data validation, data forms, navigation and with accessing business entities over the network. Prism focuses on patterns for flexible, modular, loosely coupled, unit-testable applications. These patterns can of course be used in Silverlight 3.0 just as effectively as in 2.0. The combination of Prism and the new Silverlight features provide a very powerful platform for building line of business RIA applications.

We're planning the next release of Prism which will target Silverlight 3.0 (and WPF 4.0), so we're beginning to look at how we can evolve Prism to further integrate and complement Silverlight, Blend and WPF. We're especially looking forward to support the new Silverlight out-of-browser feature(!). So if you have any ideas on what you'd like to see in Prism 3.0, please send them our way!

You'll also see that Silverlight 3.0 now has some support for navigation! I was part of the team behind the navigation features in Silverlight 3.0 last year before moving to the patterns & practices team. My original design for Silverlight navigation was of course very similar to Helix. The design changed quite a bit since I left that team, specifically so that it is more compatible with WPF's navigation model. I'll be posting details on the differences between the two designs, the advantages and disadvantages of each, and how to use them together soon.

Silverlight Navigation - Part 2

dphill — Sun, 02 Nov 2008 23:47:54 GMT

Welcome to the second in my short series of articles on navigation in Silverlight!

In the first article I introduced the core Helix navigation framework and illustrated how the three main classes – Form, NavigationPage, and NavigationLink – could be used to support simple navigation scenarios in Silverlight. In this article I’ll be adding to the core framework to support more advanced scenarios. This article will take us a bit further along the road to Navigation Nirvana. You can download the latest Helix source code from here.

The Helix navigation framework uses Uri’s to link everything together within the application. Each navigable part of the application is associated with a specific Uri. The user switches between these navigable parts by navigating to the associated Uri. In the simple scenario described in part 1, each Uri simply refers to a page that’s defined in the main application assembly. By navigating to the page’s corresponding Uri, the page is created and shown in the Frame. Linking pages together in this way is very much like a traditional web application where each hyper-link refers to a distinct page by name.

However, the Helix framework is not restricted to just linking pages together by simple names and can support many more flexible and powerful navigation strategies.

The Navigation Cycle

If you look at the underlying architecture of Helix, you’ll see that it basically consists of a number of provider and handler classes chained together to make a pipeline for processing Uri’s. This pipeline essentially takes a Uri, stores it in a journal, turns it into content and then passes the content to the navigation target. The architecture separates out the key elements of this navigation process into three pluggable components. Each of these is responsible for a specific stage of the navigation process and they work together to implement the overall navigation cycle.

Let’s take a closer look at each of these:

Journal – The journal is responsible for keeping a record of the Uri’s that have been visited (or that are to be visited). The user can navigate forward or backwards through the Uri’s in the journal, or they can add a new Uri directly to the journal in order to navigate to it. Either way, once the Journal has a Uri to process, it passes it onto the navigation handler…

Handler – The navigation handler is responsible for turning a Uri into ‘content’. In part 1, the Uri referred to a page control in the application’s resources, and so the handler simply created an instance of that page control. There are more interesting and flexible ways of turning a Uri into content, as we’ll shortly see. Once the handler has the content ready, it is passed to the target…

Target – The target is the ultimate destination for the content. It is responsible for displaying the content in the UI. In part 1, the content was a page control and the navigation target was Frame (i.e. a ContentControl) which simply displayed the page control in the UI. To complete the picture, the Frame has a reference to the Journal so that it can initiate navigation as a result of the user’s interaction with some part of the UI that is contained in the Frame, say by clicking on a NavigationLink.

By plugging in different implementations of Journals, Handlers and Targets, you can implement many different navigation strategies. You can also configure the navigation strategy on a per Frame basis so you can use multiple strategies in different parts of your application, according to your needs.

A Custom Navigation Handler

To illustrate some of the flexibility of Helix, I’m going to implement a new navigation handler that supports a more powerful and flexible navigation scheme than that shown in part 1. To illustrate the various concepts and features I’m going to build a simple application for managing customers and theirs orders. In this application, the user can choose a customer from a list, review their current orders, and then edit an order. The application therefore has three pages – Customers, Orders and OrderEdit.

In part 1, the Uri’s linking pages together were very basic and just contained the target page’s name. While this basic mechanism is ok for linking simple pages together, it isn’t very flexible and doesn’t allow us to pass any parameters, context or state between pages. This means that the page itself has to figure out how to initialize itself or to retrieve any data for it to display.

In our customer orders application, the Orders page will need to know the ID of the customer whose orders are to meant be displayed. How can we tell the Orders page which customer we are interested in? Well, wouldn’t it be nice if we could pass the Customer ID parameter to the Orders page via the Uri so that it can use it to display the right set of orders?

Let's implement a custom navigation handler to do just that…

Imitation – The Sincerest Form of Flattery

If you’re familiar with ASP.NET you’ll have seen much excitement recently about the new ASP.NET Model-View-Controller (MVC) Framework. This framework provides a way for a web application to separate out its state or data into a ‘Model’ component, its UI into a ‘View’ component, and the logic that coordinates the user’s interaction with the application (by handling and responding to user input and actions) into a ‘Controller’ component. One of the main benefits of the ASP.NET MVC framework is that it helps maintain a clean separation of concerns between the web application’s data, business logic and user interface, which then allows the use of test driven development (TDD) for web application development. ScottGu has a great series of articles that describe the many powerful features of this framework.

One of the coolest parts of the ASP.NET MVC framework is the ‘routing’ mechanism which lets the developer define the format of the Uri’s in their application and which ensures that incoming page requests are routed, according to their Uri format, to an appropriate controller for processing. Essentially, routing allows the developer to define how the Uri’s are parameterized – how it’s various pieces are split out into individual values. The routing mechanism passes these parameters to the correct controller for processing. The controller typically uses the parameters to construct or initialize a View and a Model, and connects them together before the page is rendered to the user’s browser.

There are (at least) three things that I really like about this architecture:

First, it helps to maintain a strong separation between the user interface of the application, and the non-visual ‘guts’ of the application. This allows developers to focus on the application logic, while the designers can focus on the user experience. It also allows the developers to unit-test almost all of the non-visual parts of their application before it is even deployed and put in front of user.

Second, it’s an extremely powerful and flexible architecture that can very easily be tweaked to support a navigation strategy that suits my particular application. In my humble opinion, navigation is an often neglected but absolutely critical part of an application’s design. From a usability perspective, structuring the application so that the user can easily and intuitively access its various features, functions and data is hugely important. From a development perspective, being able to implement this structure in a simple, flexible and testable way is critical. There will be times when a one-size-fits-all navigation framework will simply not work well for certain types of applications (one could argue that the default Web Form model in ASP.NET fits into this category).

Third, it’s an architecture that fits extremely well in a RIA scenario. There are various scenarios where the 'application' is really a hybrid of a web host application and a Silverlight sub-application (or sub-applications). When this is the case, the user expects to be able to navigate seamlessly through the application and they don’t want to worry about whether they are in a traditional web page or in Silverlight page. The ASP.NET MVC framework helps to support this scenario.

So, to honor the great work that the ASP.NET guys have done with their MVC framework, I’m going to borrow some of their ideas!

Navigation Routes

To support the same kind of flexibility that ASP.NET MVC provides, I built a custom navigation handler (called RouteNavigationHandler) that allows the developer to define parameterized Uri’s for their application and to associate them with a controller component. There are three main classes to this implementation – the RouteNavigationHandler itself, a Route class that defines a Uri template that specifies how a Uri is to be parameterized, and a Controller class that processes the parameters extracted from the Uri. To use these classes, we simply create an instance of a RouteNavigationHandler, add one or more Route objects to associate a Uri format with a controller instance, and then hook it up to the Frame’s journal.

RouteNavigationHandler handler = new RouteNavigationHandler();

handler.Routes.Add( new Route( "[PageName]", new NavigationPageController() ) );

rootFrame.Journal.NavigationHandler = handler;

We’ll talk more about controllers in the next section. In this section, we’ll mainly focus on the Route object which is how the system parameterizes incoming Uri’s.

The above example shows a simple route that defines a Uri with a single parameter called PageName. Any Uri that contains a single value (say ‘Page1’ or ‘Page2’) will match this route. When processed, the content of the Uri will be extracted and will be stored in a parameter called ‘PageName’. The PageName parameter will then be added to a list of navigation parameters and passed to the NavigationPageController for processing. This controller looks for a parameter called PageName in the list of parameters and then loads the corresponding page, just as in the previous article.

This is just a basic example and doesn’t even scratch the surface of the flexibility of this approach, but it does illustrate how the basic system works. The following diagram shows how this example fits together.

In the above example, the PageName parameter is an example of a positional parameter - the value that this parameter will be assigned depends on the position of the value in the Uri. In this example the Uri contains only a single parameter so there is no relative positioning of parameters, but you could define two parameters separated by a forward slash like this:

new Route( "[Parameter1]/[Parameter2]", myController )

and then the first value before the slash will be assigned to Parameter1, and the second value after the slash will be assigned to Parameter2.

When defining routes, you can also define fixed fields, as well as positional parameter fields. You can also define multiple routes. In this case, the RouteNavigationHandler will look for the first matching route and then pass control to the associated controller. This lets you direct processing to a specific controller according to the exact format of the Uri.

For example, say we had a media style application and wanted to have two controllers, one to show the user’s Photo collection, and one to show the user’s Video collection. We could define two routes like this:

RouteNavigationHandler handler = new RouteNavigationHandler();

handler.Routes.Add( new Route( "/Photos/[Tag]", new PhotoController() ) );

handler.Routes.Add( new Route( "/Videos/[Tag]", new VideoController() ) );

rootFrame.Journal.NavigationHandler = handler;

The Uri ‘/Photos/Vacation2008’ would be directed to the PhotoController, which would then likely locate and display all photographs with the ‘Vacation2008’ tag, while the Uri ‘/Videos/Wedding’ would be directed to the VideoController so that it can locate and display all videos with the tag ‘Wedding’. In both cases, each controller will receive a parameter called Tag which will contain the tag value specified on the actual Uri.

We can also capture query string parameters on the Uri by appending ‘?[params]’ to the Route’s Uri template like this:

RouteNavigationHandler handler = new RouteNavigationHandler();

handler.Routes.Add( new Route( "[PageName]?[params]", new NavigationPageController() ) );

rootFrame.Journal.NavigationHandler = handler;

When this route processes Uri’s, any query string parameters on the Uri are added as name-value pairs to the navigation parameters. So for the example above, a Uri like this

MyPage?ID=17&OrderBy=Date

will cause three parameters to be passed to the controller – PageName, ID, and OrderBy (with values of ‘MyPage’, 17, ‘Date’ respectively). This is a quick way to allow arbitrary parameters to be extracted from the incoming Uri and passed on to the controller.

The Uri route defined above (‘[PageName]?[params]’) actually defines the default navigation routing strategy in Helix. It is, in fact, almost equivalent to the strategy used in the first article but with one important addition – we can now add parameters to the page’s Uri and have them passed to the target page! That job is actually handled by the navigation controller...

Navigation Controllers

Ok, so the Route object uses a template to define how parameters are to be extracted from a Uri. When an incoming Uri is matched by a Route, it extracts the actual values from the Uri and constructs named parameters, according to its Uri template, which it then adds to a collection. This collection of navigation parameters is simply a dictionary of string name-value pairs. The navigation parameters are then passed to the navigation controller specified by the route. This object does all of the heavy lifting to actually process the parameters and turn them into content ready for displaying in the Frame.

A navigation controller is simply an object that implements the INavigationContoller interface. This interface defines a single method:

public interface INavigationController

    object Execute( NavigationParameters parameters, NavigationMode mode );

The Execute method takes the navigation parameters and does whatever it needs to do to process those parameters and return the content to be passed to the navigation target.

The default PageNavigationController expects a PageName parameter. It uses this to create an instance of the specified page so it can be displayed in the target Frame. Any additional parameters added to the Uri as a query string will also be passed to the controller. It passes these on to the target page via a new method on the INavigationPage interface:

public interface INavigationPage

    string PageTitle { get; }

    bool   KeepAlive { get; }

    bool   CanNavigateAway { get; }

    void   OnNavigate( NavigationParameters parameters, NavigationMode mode );

If the target page implements the INavigationPage interface, the OnNavigate method will be called and all of the parameters from the navigation Uri will be passed to it. The page can then extract the parameters that it needs, say to retrieve data or configure itself. If the target page doesn’t implement this interface, then it is just displayed in the Frame as usual. The default implementation of this interface (the NavigationPage class) defines OnNavigate as a virtual method, so you just have to override this method if you want to handle navigation parameters on your page.

Note that this mechanism has some drawbacks (that I’ll discuss at length in the next article). In particular, having the page process the navigation parameters means that you’ll likely have way too much presentation logic in the page, which is not good because it can’t be easily unit tested. On the other hand, if you aren’t particularly interested in unit testing, or in using strong separated UI patterns, this approach has the advantage of being relatively simple and light-weight.

Navigation Link Parameters

So now we can process a Uri by extracting parameter values from it and we can pass those parameters to a target page. But how do the parameters get included in the Uri in the first place?

The NavigationLink control allows you to specify the navigation Uri so we could just specify the link explicitly and include any parameters (positional or query-string). So for example, we could have:

<NavigationLink Content="Next" NavigateUri=" MyPage?ID=17&amp;OrderBy=Date"/>

if we’re using query string parameters (note the use of & to specify an ampersand in XAML) , or something like

<NavigationLink Content="Next" NavigateUri=" MyPage/17/Date"/>

if we’re using positional parameters. This works fine as long as we know the parameter values up-front. But what about the times when, say, the link parameters depend on the currently bound item? This is the case when you use a link in a data template, say for items displayed in a list box.

It would be rather nice if we could define something like

<NavigationLink Content="Next" NavigateUri=" MyPage/{Binding ID}/Date"/>

but we can’t embed binding expressions in the NavigateUri string like this unfortunately.

In any case, since the link parameters basically define the user’s navigation through the application, they represent, in some sense, presentation logic. Embedding presentation logic in the view is bad because it means that the application navigation can’t be unit tested, and it means that the view designer has to know about the navigation scheme employed by the application.

There are a few alternative approaches that we could use to solve this problem, but by far the simplest (and I would argue, the most elegant) is to use a ViewModel to encapsulate the application’s presentation logic, including it’s navigational or workflow structure. This means that we can just do this:

<NavigationLink Content="Next" NavigateUri=" {Binding NextLink}"/>

You’ll see this in action in the sample application below, but it means that the view is largely decoupled from the navigational structure of the application, and that we can unit test the application (including the navigational structure!) without going through the UI. It also makes the view designer’s life much easier. I’ll be talking much more about how ViewModels and the Helix navigation framework can work together in the next article in the series.

Putting It All Together

With the RouteNavigationHandler, Route and NavigationController classes added to the mix, the Helix navigation pipeline now looks like this:

Since the default route and controller as described above are already setup by Helix, the only thing you really have to do receive additional navigation parameters in a target page is to implement the INavigationPage interface and extract the parameters in the OnNavigate method. If your page derives from the NavigationPage base class, you just need to override the virtual OnNavigate method.

The OrderEntry Sample Application

To see the complete system in action, let’s build our simple order entry application. In this application, we’ll define three pages – Customers, Orders, and OrderEdit. The Customers page shows a list of customers. From there the user can select a customer and navigate to the Orders page, which will display the orders for that customer. From there, the user can elect to edit an order by navigating to the OrderEdit page.

You can run the completed sample application here. Let’s take a look at how this application is put together.

First we’ll define the view model(s) for the application. In this sample, I defined a set of simple classes for Customer, SalesOrder and LineItem. In a real-world app, you’d likely define these entities based on a real database and populate the data model by retrieving data via a Data Service call. But to simplify things, I just created some dummy view model data as an application level resource:

<Application.Resources>

    <l:Customers x:Key="AppViewModel">

        <l:Customer CustomerID="1" FirstName="Orlando" LastName="Gee"

                    CompanyName="A Bike Store" Phone="245-555-0173">

            <l:SalesOrder SalesOrderID="1" OrderDate="10/15/2008"

                          ShipDate="10/21/2008" Status="Pending">

                <l:LineItem LineItemID="1" ProductID="1" OrderQty="10" UnitPrice="356.99" />

…

            </l:SalesOrder>

            <l:SalesOrder SalesOrderID="2" OrderDate="10/25/2008"

                          ShipDate="10/31/2008" Status="Pending">

                <l:LineItem LineItemID="5" ProductID="1" OrderQty="10" UnitPrice="356.99" />

…

            </l:SalesOrder>

        </l:Customer>

…

    </l:Customers>

</Application.Resources>

With the application’s ViewModel defined, we can turn our attention to the page navigational structure. For this application, I created two additional routes that define positional parameters that can be passed to the various pages.

RouteNavigationHandler handler = new RouteNavigationHandler();

NavigationPageController controller = new NavigationPageController();

handler.Routes.Add( new Route( "/[PageName]/[CustomerID]", controller ) );

handler.Routes.Add( new Route( "/[PageName]/[CustomerID]/[SalesOrderID]", controller ) );

rootFrame.Journal.NavigationHandler = handler;

Remember, the default route already allows any Uri that just contains a page name to be handled just like in the previous article. These two additional routes define routes for Uri’s that contain CustomerID and SalesOrderID positional parameters. All routes are handled by the same controller, so all of the parameters will be passed on to the target page via the OnNavigate method.

Next, let’s look at the pages themselves. The Customers page is simple. It displays the list of customers using a ListBox and lets the user navigate to the Orders page by clicking on a NavigationLink control. To display the customers, it defines a DataTemplate that defines how to render a Customer object in the UI. This data template includes a NavigationLink to the Orders page, parameterized on the customer ID. By clicking on this link, the user navigates to the Orders page and the corresponding customer ID is passed along with the parameters.

    <ListBox.ItemTemplate>

      <DataTemplate>

        <Grid>

          …

          <StackPanel Grid.Column="1" Orientation="Vertical" Margin="4">

            <StackPanel Orientation="Horizontal">

              <TextBlock FontSize="14" Text="{Binding FirstName}" />

              <TextBlock FontSize="14" Text="{Binding LastName}" Margin="4,0,0,0"/>

            </StackPanel>

            <TextBlock Text="{Binding CompanyName}" />

            <TextBlock Text="{Binding Phone}" />

            <StackPanel Orientation="Horizontal">

              <TextBlock>No. Of Orders:</TextBlock>

              <TextBlock Text="{Binding SalesOrders.Count}" />

            </StackPanel>

            <h:NavigationLink Content="View Orders..." NavigateUri="{Binding ViewOrders}"/>

          </StackPanel>

        </Grid>

      </DataTemplate>

    </ListBox.ItemTemplate>

The data template just uses a grid to show the various properties of the customer. Notice the ‘View Orders’ link binds to the ViewOrder property of the customer view model. The actual link that is constructed by the customer ViewModel is as defined by the routes above.

Things get a bit more interesting in the Orders page. The UI of this page is very similar to the Customer page in that it uses a ListBox and a simple DataTemplate to define how individual SalesOrder objects are rendered. What’s really different is that this page uses the parameters passed to it during navigation to determine which SalesOrders are to be displayed.

public override void OnNavigate( NavigationParameters parameters, NavigationMode mode )

  if ( parameters.ContainsKey( "CustomerID" ) )

    Customers customers = Application.Current.Resources[ "AppDataModel" ] as Customers;

    SalesOrders orders =

        customers.First( c => c.CustomerID == parameters[ "CustomerID" ] ).SalesOrders;

    this.DataContext = orders;

The page first checks to make sure that the incoming navigation parameters include a CustomerID. It then gets a reference to the application data and uses a simple Linq query to extract the sales orders for the specified customer. Finally, it sets the data context of the page so that the data binding expressions in the data template can take over.

Please note that, as I mentioned above, this approach is not really ideal since this kind of logic shouldn’t really be in the view’s code behind page. Also, a real application would likely get a reference to the correct data context through a data service agent rather than via a resource. I’ll be addressing these issues in the next article, but in the meantime this simple approach will suffice - this article is long enough as it is :-)

The data template for the Orders list box includes a link that’s bound to the SalesOrder ViewModel’s EditOrder property.

<NavigationLink Content="Edit Order..." NavigateUri="{Binding EditOrder}"/>

The OrderEdit page expects a CustomerID and a SalesOrderID to be passed to it during navigation, so it’s OnNavigate method looks like this:

public override void OnNavigate( NavigationParameters parameters, NavigationMode mode )

  if ( parameters.ContainsKey( "CustomerID" ) && parameters.ContainsKey( "SalesOrderID" ) )

    Customers customers = Application.Current.Resources[ "AppViewModel" ] as Customers;

    SalesOrders orders =

        customers.First( c => c.CustomerID == parameters[ "CustomerID" ] ).SalesOrders;

    CurrentOrder = orders.First( o => o.SalesOrderID == parameters[ "SalesOrderID" ] ); ;

    DataContext = CurrentOrder;

And that's it. The OrderEntry application is a simple application but I think it illustrates some of the flexibility of the Helix navigation framework. The source code for it is included with the latest Helix source code here. In addition to the additions described above, you might also notice some minor name changes and I also tidied up some of the error state handling in the Frame control.

oO------Oo

In the next article, I’ll be extending the Helix navigation to embrace separated presentation patterns like Model-View-ViewModel. This will simplify application construction significantly, add a great deal of flexibility and provide support for test driven development.

Helix is a work in progress and is still in the experimental stage, but I’d love to know what you think of it – what you like, what you don’t like, what’s missing, what should be removed. So if you have any feedback on Helix please drop me a line.

Silverlight Navigation - Part 1

dphill — Wed, 08 Oct 2008 09:44:01 GMT

This is the first in a short series of articles on navigation in Silverlight.

Navigation is an often neglected but critical part of an application’s design. From a usability perspective, structuring the application so that the user can easily and intuitively access its various features, functions and data is hugely important. From a development perspective, being able to implement this structure in a simple, flexible and testable way is critical. Sadly, Silverlight 2.0 doesn’t include any framework support for navigation. But on the bright side, missing framework features represent an opportunity to write some code!

This series of posts describes a simple but flexible navigation framework that I’ve been playing with that can hopefully fill some of the gaps in Silverlight 2.0. This first post describes the core elements of the framework and shows some of its basic features. In subsequent posts, I’ll be talking about how the navigation framework can be extended to support data linking, deep linking and other interesting and cool scenarios.

This article coincides with the recent release of the Silverlight 2.0 Release Candidate and all of the sample code is built for it. If you haven’t done so already, install RC0 and the VS2008 tools from here.

Vanilla Silverlight Navigation

If you create a new Silverlight 2.0 project in Visual Studio, you’ll get a project that contains an Application class and a UserControl ‘page’ class. The Application class creates an instance of the page class and sets it as the root visual. Unless you’re building a really small app with a very simple UI, you’ll likely need to add other pages and user controls to your application and then implement navigation by manually hiding, showing or replacing bits of the UI within the root page. In other words, you’re pretty much on your own when it comes to navigation in Silverlight. This is a bit of a pain and means that you have to write code that’s closely tied to the UI and hard to test.

WPF on the other hand provides a fairly flexible navigation system based on Pages hosted in Frames and linked together by Hyperlinks. The Frame class provides a journal and UI so the user can also navigate forward and back through a series of pages. In an XBAP application, the root journal is even hooked into the browser so you can use the browser’s forward and back buttons to navigate pages within the hosted XBAP application.

In general, I think WPF’s navigation model is pretty nice, though I find it can be a little inflexible and somewhat complicated at times. The navigation framework presented here is similar in a lot of ways to the WPF model but (I think) it is simpler and more flexible. In particular it address three of my main grievances with the WPF model – it provides an ‘open’ linking model, it makes it easier to pass state between pages, and it allows you to more easily unit test the navigational structure of your app.

However, I haven’t tried too hard to maintain any level of compatibility with WPF – some of these additional features and capabilities would be difficult to implement in WPF – but the basic model should be familiar to those who are familiar with WPF's model.

A Quick Tour Of Helix (not the one in Oregon)

When playing with or learning about a new technology, I like to build a ‘playground’ project where I can experiment, try out a few ideas, build various bits of an application, and generally see how things fit together. In this case, the playground project was called Helix (named after a small town in Oregon that I spotted on a map once and thought would make a cool code name). Over time, Helix grew into the prototype navigation framework presented here.

Just as in the WPF navigation model, there are three central concepts in the Helix navigation framework – Frames, Pages and Hyperlinks. Each of these are represented by a specific control class:

Frame – The Frame control is the center of the navigation framework. It is essentially a content control that displays and coordinates the pages within the application. Frames can be nested and can display a UI that allows the user to navigate through a series of pages using forward and back buttons. The Frame control provides various events and methods for navigating to pages or for traversing the journal programmatically.
Pages – Pages are really just user controls that get displayed in a frame. As the user navigates through the application, pages are created, initialized and set as the content within a Frame control. Pages can implement an optional interface that allows the page to interact and control some aspects of the navigation process. Pages are referenced by a Uri. Most of the time the Uri is a direct reference to the page, but sometimes the reference can be indirect (more on this later).
NavigationLink – The NavigationLink control encapsulates a Uri to a page. When the user clicks on the NavigationLink, the nearest parent frame navigates to the page specified by the Uri.

I’ve provided the source to the core of the Helix navigation framework that contains these three controls along with a sample application here. I’ll be adding to this core library over the next few articles in this series, but for now let's see how these core pieces fit together...

The Sign-Up Sample

To see these classes in action, I built a simple Silverlight ‘Sign-Up’ application that allows a user to create a new account. You can run the sample application live here.

The application consists of three main pages. The first page allows the user to enter some basic information about themselves (name, age, gender, state, etc) , while the second page allows them to enter their email address, password and a secret question. The last page is a simple confirmation page with a link back to the first page.

To build this application, I started with a new Silverlight project and added a reference to the Helix library. Then I added Frame control to the root page (the control that is set as the root visual by the application class) like this:

<h:Frame x:Name="rootFrame" />

[You'll also need to add an xmlns reference to the Helix library to define the h: prefix]

Next, I added three user controls, called Page1, Page2 and (rather imaginatively) Page3. These contain the UI for each of the steps in the sign-up process. To link these pages together, I added a number of NavigationLink controls and set their NavigateUri properties like this:

<h:NavigationLink Style="{StaticResource NavLinkButtonStyle}"

                  Content="Step 2" NavigateUri="Page2.xaml" />

The Helix library provides a default template for the Frame and NavigationLink controls (in the generic.xaml file). The default control template for the NavigationLink control is very simple (and dull), so in the Sign-Up app I decided to jazz it up a bit by restyling it as a button (this also gave me a chance to play with the Visual State Manager feature of Silverlight!). The custom NavLinkButtonStyle style is defined in the Sign-Up application’s resources. With this style applied, the navigation link looks like this:

Next, we have to add a couple of lines of code in the root page’s code behind. First we have to tell the navigation manager where to go to find the pages that are specified in the navigation links:

NavigationManager.ApplicationAssembly = Assembly.GetExecutingAssembly();

[This is hopefully a temporary measure, due to the lack of support for loading pages by name in Silverlight 2.0.]

Finally, when the application starts up we want to show the first page, so in the Load event for the root page, we programmatically navigate to the first page.

this.rootFrame.Navigate( new Uri( "Page1.xaml", UriKind.Relative ) );

If you run the application, you will be able to navigate between the pages by clicking on the navigation link buttons. That’s essentially it as far as the basics, but there are many additional features in the core framework that we can take advantage of to make the user experience much better.

Navigation Bar

You can configure the Frame class to show a navigation bar so the user can navigate forwards or backwards through the journal.

<h:Frame x:Name="rootFrame" NavigationUIVisibility="Visible" />

The frame will now display a navigation bar like this:

If the displayed page has specified a page title (see next section), it will be displayed in the navigation bar.

Navigation Pages

When you navigate to a page (remember, a page is just a user control) Helix checks to see if it implements the INavigationPage interface. Implementing this interface allows the page to influence the navigation process. The INavigationPage interface is defined as:

public interface INavigationPage

    string PageTitle       { get; }

    bool   KeepAlive       { get; }

    bool   CanNavigateAway { get; }

The PageTitle property very simply allows the page to specify a page title that the Frame can use in the navigation bar and in the journal.

The KeepAlive property allows the page to specify whether or not the navigation system should re-create a new instance of the page when the user navigates back or forward through the journal, or whether it should keep this instance alive and just re-show it. If you run the application described above with the frame’s navigation bar displayed, the user is able to navigate via page links or by using the forward and back buttons of the frame. You’ll notice pretty soon that if the user enters some data on page 1, navigates to page 2 and then clicks the back button, the data that they entered on page 1 is gone!

In a real application the pages would probably be associated with a presentation or view model that would be responsible for maintaining the state for the pages. Then, when the user returns to a page, a new page UI would be created but it would be re-bound to a presentation model that contained all of the state for the page. However, for simple scenarios, you probably don’t want to go to the trouble of creating and maintaining presentation or view models, so the KeepAlive flag provides a simple way to keep a page instance alive so that it is not recreated from scratch when the user returns to it via the forward or back buttons.

Finally, the CanNavigateAway property allows the page to veto any attempt to navigate away from it (for example, to make sure that all of the data is valid on a form before it is submitted).

Helix provides a base class that already implements this interface so you can simple subclass it to create your pages and set the required properties in the page xaml:

<h:NavigationPage x:Class="Microsoft.Samples.Helix.SignUpSample.Page1"

...

    PageTitle="Page 1" KeepAlive="True">

...

</h:NavigationPage>

and in the code behind:

public partial class Page1 : NavigationPage

...

Navigation Error Handling

What happens if you specify a Uri to a page that doesn’t exist or you mistype the Uri? You might have noticed in the Sign-Up sample links to the privacy policy and the terms of service in the top right hand corner. If you click on these, you will see an error message saying that the pages couldn’t be found. These links were added to show how Helix handles navigation errors. If there is a problem locating or loading the page specified by the Uri, the error is bubbled up to the Frame where it can handle it in one of two ways.

First, the Frame will fire a NavigationFailed event which you can sink to provide whatever error handling your app requires. The Frame can also be configured to automatically show an error message. You can control this by setting the ShowErrorUI property. If this property is false, the frame won’t show any error messages and will just fire the NavigationFailed event.

You'll also notice that the default Frame template displays a mask panel over the frame's contents making the message box semi-modal. This is to prevent the user from navigating to other content until they have closed the message box.

Nested Frames

The first page of the Sign-Up sample shows how Helix can support nested frames. In this (somewhat contrived) example, the first page employs an embedded frame to allow the user to check whether their chosen username is unique. To implement this, the Sign-Up app has two sub pages that are displayed in a sub frame. When Page1 is first shown, the frame shows sub page 1, but when the user clicks on the Suggest a Name navigation link, this frame navigates to sub page 2 where the user can choose a suggested name.

<h:Frame x:Name="subFrame" BorderThickness="0">

    <l:SubPage1></l:SubPage1>

</h:Frame>

The navigation links in the sub pages are just links to the corresponding sub pages. When the user clicks on these links, the navigation request event is bubbled to the nearest frame, in this case, the sub frame on page 1. If you need to have an inner link navigate an outer frame, you can specify the name of the target frame explicitly using the TargetName property.

<h:NavigationLink Content="Jump To Page 2" NavigateUri="Page2.xaml" TargetName="rootFrame"/>

When the navigation request event bubbles up to the nearest parent frame, Helix will check to see if a target name is specified and if it matches the current frame's name. If it doesn't match, the request continues to bubble up. If it does match, it is marked as handled and the event bubbling is halted.

Under the Covers

The sample and the features described above represent only the core part of the Helix navigation framework. In subsequent articles I'll be going into more detail on how to extend the framework to do things like data linking and deep linking. In the meantime, it's worth taking a quick look at the underlying architecture of Helix.

The Frame class has a reference to a Journal Provider (which implements the IJournal interface). The journal is responsible for maintaining forward and back lists of pages. Each entry in the journal is a JournalEntry object. This object represents the page in the journal and coordinates the keep alive and page title behavior. By default, the frame will create an instance of the SimpleStackJournal provider. This is a simple implementation of a stack based journal.

The journal in turn has a reference to a Navigation Handler. The navigation handler is responsible for processing page Uri's and for creating and initializing the pages that they refer to. Navigation handlers implement the INavigationHandler interface. The default navigation handler (PageNavigationHandler) only handles simple page Uri's that specify the page by name - e.g. "Page1.xaml".

[I should point out that the implementation of this handler is a little hacky because Silverlight doesn't really have a nice way of creating or loading controls by name. Instead you have to load the xaml as a resource and then parse it to get the corresponding class name and then create an instance of that class. Nasty. Hopefully this is a temporary limitation of Silverlight, or I can figure out a more robust way of doing this soon.]

Once the navigation handler has created and initialized the page, it is passed back to the journal provider where a corresponding journal entry object is created and added to the stack. The journal then sets the content on the target frame via the INavigationTarget interface which it implements.

In the following articles, we'll be plugging in different implementations of journal providers, navigation handlers and navigation targets to illustrate the flexibility of this design.

The Helix navigation framework is still a work in progress but I hope you find it useful and/or interesting. Let me know what you think, or if there are any features or scenarios you would like to see tackled.