NSSplitView: Many subviews and ViewControllers, best practices

  • I have an NSDocument-based app.

    The NSDocument's window has at it's root, an NSSplitView with 7 separate
    panes/subviews... A Source list on the left and several panes to the right
    with horizontal and vertical splits.

    In one pane, I need to have three different views supported by an NSBox that
    I can swap the views out (for icon, thumbnail and list view modes). These
    views all need access to the same NSArrayController.

    What is the best way to structure this?

    Should I have an NSViewController and nib for each pane?

    Should the pane-views be in the Document Nib with classes for each one to
    act as a controller (with an outlet to a view)?

    I currently do it this way but use a subclass of NSSObject rather than
    NSViewController since NSViewController seems to want to load it's views
    from a nib rather than having a bunch of views lumped together in a main
    nib.

    Thoughts?

    I'll end up with SourceListViewController, DetailViewController,
    ListViewController etc.

    All these need to be aware of each other... Just wondering the best place to
    store the views themselves in IB... Separate nibs or all in one nib with
    outlets to find the views when needed.

    Thanks.
  • On 21/05/2013, at 6:39 PM, Trygve Inda <cocoadev...> wrote:

    > In one pane, I need to have three different views supported by an NSBox that
    > I can swap the views out (for icon, thumbnail and list view modes). These
    > views all need access to the same NSArrayController.

    Have you considered using a tabless NSTabView? For view swapping they are usually a bit easier to deal with than managing it yourself and it naturally leads to an answer to the rest of your post...

    > What is the best way to structure this?
    >
    > Should I have an NSViewController and nib for each pane?

    I'd just put it all in one nib. While it can become large, it's very unlikely you'll run into obvious performance problems. If it's in one nib, then hooking everything together becomes a perhaps lengthy but essentially trivial exercise, leaving you with only the task of writing the controller logic and not a whole lot of potentially troublesome view management logic.

    Depending on the complexity of your views, a separate controller might be best for each, or a single controller than knows about the different aspects of the data. Or a combination of the two - in similar circumstances I've ended up with a separate controller for each view type, and a master controller that refers to an instance of the separate controller, whichever is needed for the currently active view(s). By designing a common protocol or API for the subcontrollers, the master controller can treat every one the same, regardless of what view type the user chooses.

    --Graham
previous month may 2013 next month
MTWTFSS
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    
Go to today