Changing Views Within a Prism Module?

views:

439

answers:

Changing Views Within a Prism Module?

So I have a PRISM v2 (M-V-VM) application up and running. It's 4 modules that load into a tab control. Great. Now my question is - where to go from here? Most tutorials seem to stop at this point.

Maybe I'm overthinking this, but it almost seems like I'd need each module to be its own PRISM application, but that can't be right.

Please help a PRISM n00b figure out where to go from here.

What I'm looking to do next: Each tab (module) has its own toolbar with buttons, etc. Clicking a button should change the content (view) below the toolbar. How to achieve this (correctly) with PRISM? Each module (tab) should have control over its content, however, clicking cetain buttons in one tab may trigger an event in another tab (hence the use of PRISM).

So what's the correct-PRISM way to change views within a module?

+3 A:

I think you are thinking about this a bit hard. I'll explain.

What is commonly referred to as the "Shell" should contain all of your navigation controls. For example, if I wanted a tabbed UI, my Shell would contain a tab control (usually you'd decorate that TabControl with a RegionName, like "ShellTabs").

Your Modules will contribute views to these shell elements. So let's say you have the email module, it will contribute an inbox view to your collection of tabs. It could contribute these views by registering them with the RegionManager for the app (like registering your view with the Region called "ShellTabs").

Modules don't have to contribute anything visual. I have one module in our app that takes care of logging and other background processes.

Hopefully this clears up some of the nomenclature and helps you know what the responsibility of each part is.

Anderson Imes 2010-01-06 20:03:50

@Anderson: from this comment "the "Shell" should contain all of your navigation controls"... Do you recommend that something like a Ribbon Control and its related tabs/groups/buttons reside in the Shell?

Metro Smurf 2010-01-07 14:53:37

That's how I would do it. The Ribbon Control is a little more complicated because it can be contextual, so it would likely involve a little more work and something more comprehensive than IRegionManager to register views. In fact I'm not 100% sure what the Ribbon inherits from, so it's possible if you wanted to use RegionManager at all you'd have to write a RegionAdapter for it. If you get something like that working, I'd like to see a sample!

Anderson Imes 2010-01-07 15:34:33

This is only if you want Modules to contribute to the navigation control itself (like the ribbon control). If you want one module to actually provide the whole ribbon *and* its contents, you wouldn't necessarily need to put that navigation control in the shell. Especially in the case of the Ribbon, though, I think it would be more flexible to include it as a resource of the Shell that other modules can contribute to.

Anderson Imes 2010-01-07 15:54:38

Would you mind if I contacted you off-list to continue this conversation? I've found the most flexibility when the Ribbon project is aware of all the other projects (modules). Your comment confirmed the direction I had be going. fwiw: I have written 2 adapters for the Ribbon. One for adding Regions within tabs (for adding groups): RibbonTabRegionAdapter : RegionAdapterBase<RibbonTab>. And the other for Regions within the Ribbon (for adding tabs): RibbonRegionAdapter : RegionAdapterBase<Microsoft.Windows.Controls.Ribbon.Ribbon>.

Metro Smurf 2010-01-07 16:20:11

Certainly: [email protected]

Anderson Imes 2010-01-07 16:56:25

ansaurus

tags:

views:

answers:

Changing Views Within a Prism Module?

related questions