Master/Details with multiple views for Master and for Details

Topics: Conventions, UI Architecture
Feb 15, 2014 at 4:46 PM
I want to make a Master/Details screen in my project. The easy and simple way would be to put both master and details in the same viewmodel and view. But I would like to be able to have multiple views and switch between them for both master and details views. Furthermore, I would like to be able to hide, activate and even display multiple detail views. Of course everything is the same master/details relationship from the single collection of objects.

The question is:
What would be the best / easiest / "most Caliburn.Micro'ish" way to achieve that? Should I use a conductor? Conductor would be quite neat, methinks, being able to separate everything into smaller parts. But what would be the way to bind the details to the selected master item? I mean, I wouldn't be able to bind to SelectedItem, would I? Should I use EventAggregator? Hopefully there is some CM magic to achieve binding without using events?

The easiest way to describe what I want is by using explorer or in my case Directory Opus. I made some screenshots into a slide, to try and better display what I want:
you can take a looksee here:

Thanks in advance for any advice.
P.S. Caliburn.Micro rocks.
I'm only learning to code as a hobby, so please forgive my maybe silly questions and poor engrish :)
Feb 18, 2014 at 10:33 AM
It depends. :)
If your master and detail view-models are the same, indipendently from the actual view (which is the case, I suppose), you can explicitly bind View.Model to the master vm, and use a binding over View.Context to switch between views. The same can be done with the details part.
If, on the contrary, different view-models are used, then the best approach would be using a conductor One-Active to manage both Master and Detail view-models.

Regarding how to bind currently selected item from the master, to display the details view, consider this scenario:
  1. Your shell view-model exposes a Master view model, which is a conductor one-active.
  2. Your shell view hosts both master and detail views: the master view is bound through View.Model (not by naming convention), and View.Context is bound to a view-model property (e.g. MasterMode) that lets you select which type of view should be displayed; the details view is bound through View.Model (databound to Master.SelectedItem), and its View.Context should be bound to another propery (e.g.DetailsMode) used to select the proper details view (I am assuming the single-view-model/multiple-views scenario).
  3. The Master view is only responsible for displaying its content (e.g. the list of files), and at most it can display a summary of the currently selected item (e.g. the information available on the status bar in explorer). Multiple views should be created, to match available MasterMode values.
  4. The details view could be different, depending on the actual selected item, and for each type of item, multiple views should be created, to match available DetailMode values.
In case different view-models should be used, the shell view-model should expose a MasterHost property (a conductor one-active) and (eventually) a DetailsHost, moreover some more logic should be provided to generate details view-models when needed (I have assumed the most complex scenario, where completely different Master view-models generate multiple different Detail view-models... this is hardly a common scenario...).