Modelling docking

Topics: UI Architecture
Jul 28, 2011 at 2:35 PM

I'm using the Telerik Docking control and wondering how best to model it using MVVM and Caliburn screens and conductors.

It's quite complicated from a logical point of view, it has 5 docking areas, each of which can be split into multiple pane groups. Panes can be docked into these areas, pinned, tabbed and also floating.

Should I have one conductor for the docking area as a whole or should I have one conductor per pane group?

Jul 29, 2011 at 11:28 PM
Edited Jul 29, 2011 at 11:29 PM

In my experience, driving a docking control with a pure MVVM approach is a little painful, both for the inherent modeling complexity and the lack of a full binding support by most docking library.
It *can* be done (well, almost), but a little more "imperative" approach is usually simpler, expecially if you have to support layout customization and persistance.

For example, you might consider using the approach proposed by BladeWise here:
It boils down to using an abstraction representing the docking manager, thus allowing the application logic to "open" a VM into the desired pane. 

If you otherwise want to experiment along the pure MVVM path, I would avoid mapping 1:1 the Application Model to the docking panes structure, mostly because the shape and the depth of the resulting panes and splitter tree is not fixed.
You might use a limited number of "root" Conductors (for example a MainDocumentsConductor : Conductor<IDocumentVM>.WithCollection.OneActive and a SidePanelsConductor: Conductor<IPanelVM>.WithCollection.AllActive).
Once you have the child VMs collected by some conductors, you can dispatch them in the intended dock position (accessing the docking manager directly).
The child VMs dispatching logic could be based on some property or attribute exposed by the VM itself and on the current state of docking panes.

Does it make sense?