Как NSDocumentController вставляется в мое приложение на основе документов?

Question

Я создаю свое первое серьезное приложение Какао. Это приложение на основе документов, использующее базовые данные для постоянного хранения. Используя опции шаблона «Новый проект» Xcode, мой проект начался с пары классов по умолчанию:

• MainMenu.xib (главное меню моего приложения)
• EventDocument.xib (главное окно моего приложения)
• EventDocument.h и EventDocument.m (постоянный класс документов)

Я взял оттуда дизайн, и все это работает довольно хорошо, однако через другой вопрос Я наткнулся на NSDocumentController класса Cocoa, о котором я не знал. Этот класс, очевидно, предлагает логику по умолчанию для управления классами документов в приложении на основе документов.

Мой вопрос: как этот класс вставляется в мое приложение - если вообще - и нужен ли он мне? На данный момент я использую класс EventDocument в качестве контроллера верхнего уровня. Он выбирает пользовательский выбор из меню (древовидное представление с параметрами iTunes), отображает различные представления / контроллеры, которые обрабатывают эти параметры, и передает контекст управляемого объекта. Если NSDocumentController - это «путь», почему Apple не создает его как часть шаблона проекта ??

Answer 1

Я полагаю, вы неправильно понимаете цель NSDocumentController, возможно, потому, что его имя похоже на NSWindowController и NSViewController.

В Cocoa MVC контроллер является посредником для представления и модели.При работе с окнами контроллер обычно является подклассом NSWindowController, а в случае представлений - подклассом NSViewController.

В архитектуре на основе документов класс NSDocument является посредником междумодель, которая представляет документ и соответствующие представления и контроллеры.По сути, он отвечает за воссоздание модели на основе внешнего представления и предоставляет некоторый способ присоединения поведения контроллера, соответствующего модели и представлению.Для этого обычно используются две конструкции:

• Подкласс NSDocument эффективно выступает в качестве оконного (а также потенциально возможного просмотра) контроллера - например, путем реализации IBActions.Это должно работать для простых приложений, но может быстро привести к раздутому подклассу NSDocument, который имеет дело с чем-то большим, чем должно.Документация гласит:

  Шаблон проекта приложения на основе документа по умолчанию не наследует NSWindowController.Вам не нужно создавать подкласс NSWindowController, если вы пишете простое приложение.Однако, если вы пишете приложение с более сложными требованиями, вы почти наверняка захотите это сделать.

• Подкласс NSDocument создает настраиваемые контроллеры окон, которые, в свою очередь, реализуют поведение контроллеров, потенциально также используя контроллеры представления.

Inво многих (большинстве?) случаях нет необходимости в подклассе NSDocumentController - часть контроллера вашего приложения будет находиться внутри оконных контроллеров, контроллеров представления или вашего подкласса NSDocument.Тем не менее, в некоторых ситуациях это может быть необходимо, как объяснено в документации :

Обычно вам не нужно создавать подкласс NSDocumentController.Практически все, что может быть сделано с помощью подклассов, может быть легко выполнено делегатом приложения.Однако при необходимости можно создать подкласс NSDocumentController.

Например, если вам нужно настроить панель «Открыть», явно необходим подкласс NSDocumentController.Вы можете переопределить метод NSDocumentController runModalOpenPanel: forTypes: чтобы настроить панель или добавить вспомогательное представление.Методы addDocument: и removeDocument: предоставляются для субклассеров, которые хотят знать, когда документы открываются или закрываются.