macOS NS(Main)Menu and the responder chain

[MrFusion]

Background:
I have a custom subclass of NSOutlineView, with a custom contextual menu.
This subclass implements the target actions of the menu and

- (BOOL)validateMenuItem:(id <NSMenuItem>)menuItem

The menu items are all connected to the first responder.
This all works well.

Requirement:
The Apple User Guidelines teaches that all actions should have multiple ways to use. So, the contextual menu's are added to the main menu, and the actions are again added to the first responder, this time of the NSMainMenu.nib

Problem:
It doesn't work. Another item of the nsmainmenu whose action is implemented by the subclass of the windowcontroller does find its way through the responder chain and functions as expected. But the ones implemented in the NSOutlineView subclass don't

Tried:
Connecting the NSOutlineview with first responder in IB.
Make the NSOutlineview subclass first responder in awakeFromNib.

Requested:
euh... a tip/trick/solution, something that could help. I don't want to reimplement all these functions again the NSDocument subclass or NSwindowController subclass. That seems to be unnecessary clutter to me.

Thanks.

 

[kainjow]

Your outline view shouldn't implement the menu's actions. This is the root problem. Re-design it to have the methods in your controller classes, then you won't have to duplicate method implementations for your menu bar.

 

[MrFusion]

Your outline view shouldn't implement the menu's actions. This is the root problem. Re-design it to have the methods in your controller classes, then you won't have to duplicate method implementations for your menu bar.

Ok, I'll do that. But I don't see the problem with putting actions that are only necessary for a particular view into the subclass of that view.

 

[kainjow]

Well it depends on the action. If it's something like removing an item, editing an item, rearranging items, etc., then that is not related to the view, but to the model. That should be implemented in the controllers.

If it's related to the actual view, like selecting items, then that can be implemented in the view.

What exactly are you doing in your subclass?

 

[MrFusion]

Well it depends on the action. If it's something like removing an item, editing an item, rearranging items, etc., then that is not related to the view, but to the model. That should be implemented in the controllers.

If it's related to the actual view, like selecting items, then that can be implemented in the view.

What exactly are you doing in your subclass?

Both reshuffling and selecting of the items. I am redoing it anyway. Turned out that deleting items in a NSOutlineView is not straight forward.

 

[Krevnik]

Both reshuffling and selecting of the items. I am redoing it anyway. Turned out that deleting items in a NSOutlineView is not straight forward.

It isn't, because the NSOutlineView has no 'data'... it queries the data source. Usually the sort of model I take when providing data to a view is the view is only subclassed if I want custom display behavior, or something I absolutely can't do without a subclass. I use a data source to manage the items that the outline view displays. It is the one that should reshuffle, select, etc... It is aware of the view, the view is aware of it. Objects that need to manipulate the view need to talk to the data source. Menu items related to a view usually go in a controller separate from the data source, and talk to the data source to manipulate things.

I tend to take the approach of many smaller pieces of functionality, rather than trying to shove things into a single related class. I think in a big complex app, doing it this way has let me subclass very minimally, and use Apple's own controls for the behavior I want.