One of the reasons I prefer to manage navigation as an event, rather than a strongly typed interface or handler, is because it allows for so much flexibility and extensibility in the navigation pipeline. In my Jounce framework, for example, the basic navigation event simply wires up an instance of a view to a view model and makes no presumptions about where that view belongs - it leaves positioning the view to the developer. The region manager simply listens for navigation events and passes the views off to region adapters without worrying about how they are wired, so it automatically handles the view simply by extending the pipeline by listening for the message as well. This same model makes it incredibly simple to place views in child windows using the new Silverlight 5 Out-of-Browser feature.
The first thing I'll do is create a controller to listen to navigation messages. It will expect a specific parameter to be passed that indicates when the view should be passed to a window. If that parameter exists, it will use parameters for height, width, and title to spin up the new window. A more complete implementation would store those literals as constants. Here is the shell for the class that implements the listener and subscribes to it:
[Export]
public class WindowController : IEventSink<ViewNavigationArgs>,
IPartImportsSatisfiedNotification
{
[Import]
public IEventAggregator EventAggregator { get; set; }
[Import]
public IViewModelRouter Router { get; set; }
public void OnImportsSatisfied()
{
EventAggregator.SubscribeOnDispatcher(this);
}
Now the handler. The handler will check the parameters for a special "OpenInWindow" parameter that must be set to true. It will only respond when that's the case, and everything else goes through the normal view routing. Because the project uses region management, there is no conflict because these views will not be routed to specific regions. First, if the parameter doesn't exist, the method simply returns. Note the use of the Jounce extension methods that conveniently cast the parameter to a specific type:
public void HandleEvent(ViewNavigationArgs publishedEvent)
{
var parms = publishedEvent.ViewParameters;
if (!parms.ContainsKey("OpenInWindow") ||
!parms.ParameterValue<bool>("OpenInWindow"))
{
return;
}
}
Next, the router is used to get the view model that is mapped to the view, then spin up a non-shared instance of the view and view model. This allows multiple instances to be created and therefore supports multiple windows with the same view/view model combination. The method to get the view takes an object for a parameter that it will set to the data context of the view. Jounce is smart enough to recognize when that object is a Jounce view model, and will take the additional steps of wiring in visual states and calling the InitializeVm and ActivateView methods on the view model. Notice that the parameters are passed into the view model as well - Jounce will pass these in when it attaches the view model to the view.
var viewModelTag = Router.GetViewModelTagForView(
publishedEvent.ViewType);
var viewModel = Router.GetNonSharedViewModel(viewModelTag);
var view = Router.GetNonSharedView(
publishedEvent.ViewType,
viewModel,
publishedEvent.ViewParameters
as Dictionary<string, object>);
Finally, the window is opened with the view set as the content:
new Window
{
Title = parms.ParameterValue<string>("WindowTitle"),
Width = parms.ParameterValue<int>("WindowWidth"),
Height = parms.ParameterValue<int>("WindowHeight"),
Content = view,
Visibility = Visibility.Visible
};
That's all there is to it. The controller must be imported somewhere to begin listening for events. Then you can simply export the view with a tag like [ExportAsView("MyView")] and publish the navigation using the Jounce extension methods to turn the view tag into a navigation event and add parameters:
var window = "MyView".AsViewNavigationArgs()
.AddNamedParameter("OpenInWindow", true)
.AddNamedParameter("WindowTitle", "My View Title")
.AddNamedParameter("WindowHeight", 300)
.AddNamedParameter("WindowWidth", 600);
EventAggregator.Publish(window);
Of course you can get even more clever with how you obtain the title or set the sizes, and now opening a child window is not only as easy as publishing an event, but also fully testable in your view models because you can mock the controller for testing.This technique is demonstrated in detail in the chapter about OOB applications in Designing Silverlight Business Applications: Best Practices for Using Silverlight Effectively in the Enterprise (Microsoft .NET Development Series)
