I'm building a source-list iTunes style app. I have a big xib that handles the primary window and is owned by the App Delegate. The SourceList (a view-based NSOutlineView) is controlled by a NSViewController subclass that is also the delegate and datasource. When setting up the NSTableCellViews in the SourceList controller class's delegate method, I'm forced to use the nib's owner as the App Delegate:
The docs say that I'm supposed to use target action to receive edit info from the user, but doing so requires the action to be wired to the nib's owner which is the app delegate, not my preferred class of the SourceList Controller. I'm trying to figure out how to structure my controller classes and nibs so that everything is properly encapsulated, and this is driving me nuts.
All of Apple's sample code features "god objects" where the controller for the sourceList is also the controller for all of the stuff in the nib such as buttons and windows etc. This avoids the file's owner problem but creates code with controllers that aren't well defined. I certainly don't want my app delegate to also be the delegate and data source of my source list, because it's already managing a lot of stuff (the toolbar at the top, the split view, loading the appropriate contentViews etc).
The only solution that comes to mind is breaking the Source List into it's own nib with the file's owner being my source list controller object. I guess this is reasonable, but it seems foreign to all of the examples i've ever run across. I'm hesitant to stray too far from the examples I've seen and worry there might be some negative unintended consequences by going this route. Generally speaking, common patterns are supposed to be easy with Cocoa, which is why I suspect I'm overlooking a much more elegant solution. Any suggestions?
Code:
-(NSView *) outlineView: (NSOutlineView *)theOutlineView viewForTableColumn: (NSTableColumn *)theTableColumn item: (DISourceListNode *)theItem
{
...
NSTableCellView *rTableCellView = [theOutlineView makeViewWithIdentifier: @"MainCell" owner: [self appDelegate]];
...
}The docs say that I'm supposed to use target action to receive edit info from the user, but doing so requires the action to be wired to the nib's owner which is the app delegate, not my preferred class of the SourceList Controller. I'm trying to figure out how to structure my controller classes and nibs so that everything is properly encapsulated, and this is driving me nuts.
All of Apple's sample code features "god objects" where the controller for the sourceList is also the controller for all of the stuff in the nib such as buttons and windows etc. This avoids the file's owner problem but creates code with controllers that aren't well defined. I certainly don't want my app delegate to also be the delegate and data source of my source list, because it's already managing a lot of stuff (the toolbar at the top, the split view, loading the appropriate contentViews etc).
The only solution that comes to mind is breaking the Source List into it's own nib with the file's owner being my source list controller object. I guess this is reasonable, but it seems foreign to all of the examples i've ever run across. I'm hesitant to stray too far from the examples I've seen and worry there might be some negative unintended consequences by going this route. Generally speaking, common patterns are supposed to be easy with Cocoa, which is why I suspect I'm overlooking a much more elegant solution. Any suggestions?
Last edited: