Prism Navigation

Hi Chris,

There are several ways to select a view for a view-model.  We created DockSite to work just like any normal ItemsControl, so all the same sorts of view creation methods you use in an ItemsControl are available to you in DockSite.

1) One option that you saw in the sample was to use view DataTemplates that target certain view-model types, but as you said, you have reasons for not using that.

2) Another way is to create a DataTemplateSelector object to assign to the ToolItemTemplateSelector property.  You could use any logic you want in that selector class to programmatically return a DataTemplate based on the passed-in view-model.

3) Yet another way is to make a class that inherits DockSite and override methods like PrepareContainerForItemOverride and ClearContainerForItemOverride.  Again in this scenario you can provide programmatic logic and you could specify an exact content element if you'd like instead of using a DataTemplate.

We don't have anything built into Docking/MDI that will harness Prism Navigation directly but perhaps you could use the #2 or #3 options above and programmatically access the navigation data to get a view for your view-model?

Thanks. 

I almost have it working by modifying the DockSiteRegionBehavior class from the sample to accomodate prism navigation as well. It'd be great if this was supported by the control as prism navigation is the suggested practice from the maintainer of Prism.

Correct me if I'm wrong, but from the sample, all objects added to the region (visible or not) will remain in memory since they are deactivated in the region, and not removed.

I believe that is correct.  A closed docking window will be retained in memory since it is still registered with the DockSite.  Once a docking window unregisters from the DockSite, then it can be freed from memory.  Generally document windows destroy themselves (unregister from the DockSite) on close but tool windows do not.  Tool windows are meant to be reused and reopened.