Multiple Regions and Views

Topics: Prism v2 - Silverlight 2, Prism v2 - WPF 3.5
Mar 27, 2009 at 11:55 PM

I am looking for advices or samples to achieve following scenario:

I have a shell with one region where I display a view showing 2 buttons. If I click on button 1, I want to display a new view with 2 regions (named templateView2Regions) and if I click on button 2, I want to display another view with 3 regions (named templateView3Regions). Are scope regions the correct way to solve this?

Then in each region of each templateView, I display the 3 same buttons allowing to choose a view (view1, view2, view3). All combinations would be accepted: for instance in templateView2Regions, displaying view1 two times would be correct. Therefore I cannot use View Injection before user's choice. How can I tell view1 to be injected in the correct region(s) ?

 Thanks for your help


Mar 28, 2009 at 6:35 PM

Hi Alain,

To display or hide a view in a region, a ContentControl has to be used to define your region in your shell.xaml file (assuming yor are defining your regions there). e.g.

<ContentControl x:Name="templateView2Regions" cal:RegionManager.RegionName="templateView2Regions"/>

Then, you can add your views to the regions. e.g.

            IRegion region2 = this.regionManager.Regions["templateView2Regions"];

When you click a button, you can display or hide a view by activating or deactivating the veiws:


Remember that adding a view to a ContentControl does not display the view. You need to activate it to display it.


Mar 31, 2009 at 5:23 PM
jie thanks for your reply.

If I go further in my scenario: in the shell I load one module and display its view. This view shows two buttons enabling to choose either a template view with 2 regions or a template view with 3 regions.
What would be the best practice?
-To have a controller in the same project as the shell?
-To have another module with a controller to display the correct views?
For those "navigation" steps (displaying a view A, B or C) is it a good solution to use event (with EventAggregator) ?

Mar 31, 2009 at 9:18 PM
Composite WPF can help you with building WPF applications with  loosely coupled modules. In that sense, I'd suggest that you have another module (which normally means another project in your solution), unless your application is a simple one. This way, you would be able to separate the main project (which contains the shell) and the view project, and deal with them separately, since Composite WPF can make them loosely coupled.

Events can be used for navigation, when you do not need responses. I guess that's your situation. If your event publisher(s) and subscriber(s) are in the same module, either EventAggregator or .NET event can be used. Whereas, If they are in different modules, EventAggregator should be used then.

Apr 1, 2009 at 9:49 PM
This module containing the controller will have to display wiews of other modules. Would you handle it as a real module (implementing IModule interface like other modules) or more like the Infrastructure project used to communicate between modules?

I would use EventAggregator in the controller to subscribe to events published in ViewModels in order to load the next view to display. Do you think it makes sense?
Apr 2, 2009 at 1:48 AM
Edited Apr 2, 2009 at 4:43 PM
I would make this module a real module. This module would be very likely depended on other modules, and should not be your infrastructure project. In case you do have something in the module that needs to be shared by other modules, try to separate them out and move them to your infrastructure project.

I'm not sure if you are using the MVVM, MVC, or other similar patterns, but it's perfectly fine to use EventAggregator, provided that your ViewModels does not need reponses from the controller when it publishes events.