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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

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

Как правило, вам не нужно подкласс NSDocumentController. Почти все, что может быть сделано путем подклассификации, может быть сделано так же просто делегатом приложения. Однако, если вам нужно, можно подклассифицировать NSDocumentController.

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