About wpf navigation pattern.

Topics: Prism v4 - Silverlight 4, Prism v4 - WPF 4
Feb 26, 2011 at 2:22 PM

Hi all,

I want have the content of a Grid's row (not DataGrid) bound to a given DataContext property. In others words, I want that the UserControl that appear in, lets say... row 1 of my Grid, change when the DataContext property XX change from an UserControl to another UserControl. Any idea how do that?

What I'm trying to achieve is a loosely couple UI consisting of a Shell (main window) with placeholders (lets said that the placeholders are Grid's row 0 and Grid's row 1 for example), but with the capability to allow the content of such placeholders be changed from any of the placeholders, How? well, binding the Commands property of some placeholder controls to the Shell DataContext's Commands (the ShellViewModel), Shell DataContext by hierarchy is the DataContext of all controls inside any placeholder that don't overwrite the DataContext property. Then inside the implementation of such commands change Shell's DataContext property XX.

More specifically, I want that the navigation controls (UI) of my applications can be easily changed without affect the semantic of the navigation, and the only thing that come to my newbie mind after read about MVVM is the above approach. Do you have a better idea? Is that correct or is too loosely couple ;)

The idea is have a Shell with placeholders, and that the Shell expose Commands through its DataContext (the Shell's ViewModel) to any of the UNKNOWN AT FRONT UIs components that will fill such placeholders. Such commands can be saw as a kind of API/Interface used to interact with, for example, the navigation system. I'm in the right path? or I'm just saying newbie crap.


Frank Abel

Feb 26, 2011 at 4:17 PM
Edited Feb 28, 2011 at 8:05 PM

Well, after think and read more I get a way:

<ContentControl Grid.Row="1">
    <Binding Path="CurrentView"/>

Still want know what the Gurus of the composite world have to said about this way of decouple the Shell components while allow that such components change the system navigation/view-state.

Feb 28, 2011 at 6:20 PM

Hi Frank,

In order to achive what you've mentioned in your first question, you could bind the Grid's Children collection to an observable collection in your ViewModel.

As for the approach you've chosen to decouple the UI from the navigation semantics seems a valid possibility to achieve that requirement.


Miguel Bronzovic


Feb 28, 2011 at 8:03 PM

Hi Miguel,

Thanks for your reply.

I will try to explain what I'm doing in order to receive criticism again or to favor this pattern or whatever thing it is. May be this pattern isn't new and I'm reinventing the wheel, but I want share it with the community to contribute with something useful or realize how crazy I'm.  I don't have time to research more right now cos I already consume all the time I can spent learning without get in troubles in my current project ;) so here we go:

What I'm proposing is a way to organize the Views of an application in the composite world. I'm thinking that may be in some scenarios is good exposes a set of properties to the Shell through its ViewModel and consider such properties as the semantic definition of the UI. For example, in the following Shell:


Grid> <Grid.DataContext> <local:ShellViewModel /> </Grid.DataContext> <Grid.RowDefinitions> <RowDefinition/> <RowDefinition/> <RowDefinition/> </Grid.RowDefinitions> <views:MainMenuView Grid.Row="0"/> <ContentControl Grid.Row="1"> <Binding Path="CenterPlaceholder"/> </ContentControl> <views:FooterView Grid.Row="2"/> </Grid>

are referenced two views statically (the MainMenuView and the FooterView) and one other view dynamically (the view that is assigned to the CenterPlaceholder ShellViewModel’s property), so what is showed at a given time in the row 1 depend of the implementation of the CenterPlaceholder property. If then we add a set of ICommands to the ShellViewModel and said that those ICommands are the way to change the semantic status of the UI (the navigation system), we got a system with some advantages. To clarify let’s suppose that exist another two views, ProductListView and CustomerListView, and due to, two ShellViewModel  ICommands named ShowProductListViewAtCenter and ShowCustomerListViewAtCenter that basically switch the CenterPlaceholder ShellViewModel’s property to one view and to the other.


Expect you get the point, pls, don’t look the logic of the example or how tuned is the code, etc. get the idea and talk about it, again or to favor.


Using the above approach we can get the following advantages in some scenarios:

1-      Very clear division between the navigations views (MainMenuView in the above example) and the navigation semantic (what each navigation action imply in term of UI semantic changes).

2-      Very clear division between navigation semantic and the navigation-system-layout UI.

3-      Possibility of easily implement view caching when desired, think that a given view can be stored as a ShellViewModel field and just created the first time its corresponded property is acceded, saving processing when user request show other view and the it again through the navigation system.

Exist others pro, but let’s first gurus tell me how wrong I’m ;)

Miguel, if we store the dynamic views in a Children collection we lost ones of the points of this pattern, cos then designers can’t arrange the placeholders/dynamic-views (the semantic of the UI) to define the UI as they want.


Frank Abel

Mar 1, 2011 at 6:02 PM

Hi Frank,

The approach you're mentioning seems right, but it might have one drawback regarding the tight coupling of the shell with the views that are going to be placed in it. That is to say, by placing such commands in the ShellViewModel, you are bound to place the logic for achieving the operations such as showing a customer list in the Shell project. The guidance in Prism shows that it's possible to place such logic in the modules themselves, in order to achieve a loose-coupling between your components.

I hope you find this helpful.

Guido Leandro Maliandi

Mar 1, 2011 at 9:25 PM

Completely agreed with you Guido. I just put the ICommands there to put it at some place, but don't mean that such commands must be fixed in the ShellViewModel. In fact, I think that the location of a given ICommands set is determined for to witch UI semantic items the ICommand set interact, so, ICommands for a set "UI semantic elements" must be as near as possible regard modularity without break the access mechanics (datacontext in this case).


Thank for your reply

Frank Abel