MVVM ButtonGroupViews

Sep 27, 2013 at 10:40 PM
Edited Sep 27, 2013 at 10:47 PM
EDIT NOTE: The subject on this really should be "RibbonGroupViews"!

Thanks, this gave me a nice starting point!

When using the XamRibbonWindow as the Shell, and XamRibbon as a Region, it can be very annoying trying to figure out how to inject views appropriately. Unfortunately, you can't use the XAML designer when sub-classing RibbonTabItems, RibbonGroups, or even individual RibbonTools. It's very awkward to switch back and forth from raw XAML and the design-view of something that can host the "view" you are constructing.

Your solution for an adapter works around that reasonably well. But I might suggest that the granularity can be changed so that Views are injected into RibbonGroups via the available WrapPanels available for RibbonTools (Vertical or Horizontal).

The XAML designer handles panels just fine, so it allows for a reasonable visual design-time experience, while still allowing final composition to happen in a flexible way. There are really three good reasons why you don't need granularity down to the Tools level:
  1. There is really not much point to having a Region Adapter actually wrap the individual tools for you. After all, you already know by the type of adapter you are creating that you'll be using ButtonTools and not Buttons.
  2. This is a VIEW we are trying to inject into a region, and not incidental COMMANDS. Our commands will sometimes be localized in the View, and sometimes they'll be bound (or "evented") out to the ViewModel. But that doesn't really matter. The primary thing we are trying to do in the Ribbon is interact with the user.
  3. There's a reason why the container is called a Group. We usually need several tools to work together to achieve some degree of modularity in the application logic. And we need a view than can coordinate its constituent controls enough to do something more advanced than show a popup dialog.
Imagine that you have a large team of developers working on various modules for a complex composite application (which is really the scenario where a framework like Prism is essential). And some of those modules may need to inject views into some region of the RibbonContentHost (Ribbon, QAT, ApplicationMenu, StatusBar). A module developer creating views for such an application needs at least SOME control over what a user is going to experience when they are presented with a group of UI elements.

In short, it is my contention that a RibbonGroup is the MINIMUM granularity required for the region adapter. Then we only really have to worry about Tabs and ContextualTabGroups. But at that higher level, I think your solution will work quite well for my purposes.

To be fair, the granularity of your solution might possibly allow a team more flexibility, such as the ability to switch more easily away from using the Ribbon at all. But if the views are designed properly in the first place (i.e. with minimal code-behind), that shouldn't make much of difference.

Sep 28, 2013 at 1:29 AM
Actually, forget all of that post.

I just watched the series by Brian Lagunas (Infragistics): Series - Building IG Outlook

He has the region adapter fleshed out to handle associating ribbon tabs with Views very easily.
Marked as answer by bluecreststudio on 2/19/2014 at 12:03 PM