| Comments

One of the new features in Silverlight 3 is providing an application navigation framework via the Frame and Page controls in the APIs.  If you saw my guide to Silverlight 3, you may have seen the section on navigation which describes the functionality and as well has a link to a video tutorial about it.

I wanted to augment that tutorial with some additional information about URI routing, which I think is one of the great features of the framework.  You see typically your UriMapper might have a 1:1 mapping and look something like this (note in my sample here I’m putting this in App.xaml, but the model may change in the future of where you can/should place UriMapper):

   1: <Application xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   2:              xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
   3:              x:Class="NavigationSample.App"
   4:              xmlns:navcore="clr-namespace:System.Windows.Navigation;assembly=System.Windows.Controls.Navigation"
   5:              >
   6:     <Application.Resources>
   7:         <navcore:UriMapper x:Key="uriMapper">
   8:             <navcore:UriMapping Uri="About-Us" MappedUri="/Views/AboutPage.xaml" />
   9:         </navcore:UriMapper>
  10:     </Application.Resources>
  11: </Application>

But what if you still wanted to provide friendlier routes, obfuscate the physical location of the view, but handle the default scenario?  You can as long as you follow your own naming conventions.  Take for instance if we contain all our pages in a folder called Views in our application.  We could then map our routes like this:

   1: ...
   2: <navcore:UriMapper x:Key="uriMapper">
   3:     <navcore:UriMapping Uri="{}{page}" MappedUri="/Views/{page}.xaml" />
   4: </navcore:UriMapper>
   5: ...

You could also follow some naming conventions if you wanted to make sure you limited it to only pages or something so you require the view page to be named SomethingPage.xaml and then can have a route like:

   1: ...
   2: <navcore:UriMapper x:Key="uriMapper">
   3:     <navcore:UriMapping Uri="{}{page}" MappedUri="/Views/{page}Page.xaml" />
   4: </navcore:UriMapper>
   5: ...

The navigation routes are read top down so you can still have explicit (or additional) routes in addition to the default.  So given:

   1: ...
   2: <navcore:UriMapper x:Key="uriMapper">
   3:     <navcore:UriMapping Uri="About-Us" MappedUri="/Views/AboutPage.xaml" />
   4:     <navcore:UriMapping Uri="History" MappedUri="/Views/AboutPage.xaml" />
   5:     <navcore:UriMapping Uri="{}{page}" MappedUri="/Views/{page}.xaml" />
   6: </navcore:UriMapper>
   7: ...

A request to About-Us, History or About would navigate to /Views/AboutPage.xaml regardless.  This provides you some flexibility and granularity in your implementation and also provides additional SEO points for your content.

I really like the UriMapper in the navigation framework and have been lobbying to change the default templates Visual Studio spits out to use the UriMapper by default.  It provides you with a cleaner (and perhaps shorter) URI as well as obfuscates your “code” from your URI logic.  Be sure to check out the video if you aren’t familiar with the framework at all.

I hope this helps and would love to know what you think about the navigation framework?


This work is licensed under a Creative Commons Attribution By license.

Please enjoy some of these other recent posts...

Comments