Why is my NSOutlineView datasource nil?

Question

This is a follow-on question from my previous one relating to why my managedObjectContext was returning to nil. I thought the direction of the question would get buried

Answer 1

Most of the time, this means that you have inadvertently created two instances of your class. One is in your nib and hooked up to everything, while the other is either created in code or created elsewhere in a nib without any connections. An easy way to prove that this is happening is to log self both in awakeFromNib and some method that's seeing nil — you'll see different addresses for the two objects. You'll also find that outlineView itself is nil, since the outlet isn't hooked up to anything.

Answer 2

It looks to me like you are imposing a tree structure on the data in the controller instead of in the data model. You shouldn't have to fetch two entities into two arrays and then shoehorn them together to create your tree. The idea behind bindings is that controllers simply link the data model to the control and the control displays the object graph within the data model.

So, I think you need to back up and look at your data model again. I infer you need a data model something like this:

Client{
    name:string
    //... some other attributes
    projects<-->>Project.client
}

Project:
    name:string
    // ... some other attributes
    client<<-->Client.projects
}

You want an outline that shows Clients with their related Project objects as children.

If you use NSTreeController you would bind the tree controller to the entity Client with a child path of projects

If you use an Outline Data source, you would just fetch the Client objects sorted as you wish and then return them and their projects as needed.

The important thing here is that the outline or tree structure should be innate in the data model itself. If it is not, then you probably don't want the user looking at and thinking about the data in an outline form.

Remember as well that the data model is an entire layer of the Model-View-Controller design and is not just a dumb store of bits. It can and should contain all the logic necessary to represent the active data in the app. Arguably, the data model is the core of the app with the UI, networking or persistence tacked on as needed. Don't be afraid to put logic related to the data in the data model.