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

Приложение NSDocumentController объект управляет документами в приложении. В шаблоне разработки MVC, NSDocumentController объект является высокоуровневым контроллером. Это имеет следующую основную ответственность:

• Создает пустые документы в ответ на Новый элемент в меню File

• Создает документы, инициализированные с данными от файла в ответ на Открытую позицию в меню File

• Дорожки и управляют теми документами

• Обрабатывает связанные с документом пункты меню, те, которые Открывают Recent

Когда пользователь выбирает New из меню File, NSDocumentController объект получает надлежащее NSDocument подкласс от информационного списка свойств приложения и выделяет и инициализирует экземпляр этого класса. Аналогично, когда пользователь выбирает Open, NSDocumentController отображения объекта Открытое диалоговое окно, получает выбор пользователя, находит NSDocument подкласс для файла, выделяет экземпляр класса и инициализирует его с данными от файла. В обоих случаях, NSDocumentController объект добавляет ссылку на объект документа к внутреннему списку, чтобы помочь управлять его документами.

Большую часть времени можно использовать NSDocumentController как должен управлять документами Вашего приложения. NSDocumentController соединен проводами для надлежащего ответа на определенные события приложения, такой как тогда, когда приложение запускает, когда оно завершается, когда система закрывается, и когда документы открыты или распечатаны. Также можно создать пользовательский объект делегата и реализовать методы делегата, соответствующие тем же событиям (см. Ссылку на протокол NSApplicationDelegate).

NSDocument представляет и хранит данные документа

NSDocument базовый класс для объектов документа в архитектуре приложения — необходимо создать NSDocument подкласс для каждого типа документа Ваши дескрипторы приложения. Когда Ваше приложение работает, оно имеет NSDocument- основанный объект для каждого открытого документа. В шаблоне разработки MVC, NSDocument модельный контроллер, потому что он управляет моделью данных, т.е. персистентные данные, связанные с его документом. NSDocument объект имеет следующую ответственность:

• Управляет дисплеем и получением данных в его окнах (с помощью его контроллеров окна)

• Загрузки и хранилища (т.е. чтения и записи) персистентные данные связались с его документом

• Реагирует на сообщения действия, чтобы сохранить, распечатать, вернуться, и закрыть документы

• Выполнения и управляют диалоговыми окнами Установки Сохранения и Страницы

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

• Для отслеживания отредактированного состояния, NSDocument обеспечивает метод для обновления счетчика изменения.

• Для отмены и операций восстановления, NSDocument лениво создает NSUndoManager экземпляр, когда каждого требуют, соответственно реагирует на команды меню Undo и Redo и обновляет счетчик изменения, когда выполняются отмена и операции восстановления.

• Для печати, NSDocument упрощает дисплей диалогового окна Установки Страницы и последующую модификацию NSPrintInfo объект используется в печати. Сделать это, подклассы NSDocument должен переопределить printOperationWithSettings:error:.

• Проверить пункты меню, NSDocument реализации validateUserInterfaceItem: для управления включенным состоянием и заголовками пунктов меню Revert Document и Save (который становится, Сохраняют Версию, после, документ сначала сохраняется). Если Вы хотите проверить другие пункты меню, Вы можете переопределить этот метод, но, несомненно, вызовете реализацию суперкласса. Для получения дополнительной информации о проверке пункта меню посмотрите Ссылку на протокол NSUserInterfaceValidations.

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

Тем не менее, управление данными документа и его пользовательским интерфейсом тесно связано, который является, почему объект документа владеет и управляет своими контроллерами окна. Объект документа также управляет своим меню, которое является частью пользовательского интерфейса, потому что состояние его пользовательских команд — какие команды доступны и включают ли им — определяется состоянием данных документа.

NSDocument объект не должен содержать или требовать присутствия любых объектов, которые являются определенными для пользовательского интерфейса приложения. Несмотря на то, что документ может владеть и управлять NSWindowController объекты — которые представляют документ визуально и позволяют пользователю редактировать его — он не должен зависеть от этих объектов, являющихся там. Например, могло бы быть желательно иметь документ, открытый в Вашем приложении, не имея его, визуально вывел на экран.

Для получения дополнительной информации о разделении на подклассы NSDocument, посмотрите Создание Подкласса NSDocument.

Если Вы имеете большой набор данных или требуете модели управляемого объекта, можно хотеть использовать NSPersistentDocument, подкласс NSDocument, создать основанное на документе приложение, использующее Базовые Данные. Для получения дополнительной информации посмотрите Базовую Начальную точку Данных.

NSWindowController управляет одним окном документа

NSWindowController объект управляет одним окном, связанным с документом. То окно обычно сохранено в файле пера. Также, в шаблоне разработки MVC это - контроллер представления. Когда NSWindowController объект получает запрос от своего владения NSDocument объект, это загружает файл пера, содержащий окно, выводит на экран окно и устанавливает себя как Владелец Файла файла пера. Это также принимает на себя ответственность за закрытие окон должным образом.

Контроллер окна отслеживает его окно с помощью его выхода окна. Выход окна должен быть подключен к окну, за которое Ваш контроллер окна ответственен, как показано на рисунке 2-3.

Несмотря на то, что не требуемый, часто удобно установить Ваш контроллер окна как делегата окна, это управляет. В Вашем файле пера соедините выход делегата окна, которым Ваш контроллер окна управляет к объекту, представляющему Ваш контроллер окна — в частности, объект Владельца Файла.

XCode основанный на документе шаблон приложений не разделяет на подклассы NSWindowController, если Вы пишете простое приложение, и Вы не должны делать так. Однако, если Вы запишете приложение с большим количеством высоких требований, как типично, то Вы почти наверняка захотите сделать так. Кроме того, разделение на подклассы NSWindowController способствует лучшей инкапсуляции Вашего представления и кода модели. Для получения дополнительной информации посмотрите, что Необходимо Разделить NSWindowController на подклассы.

Разделение на подклассы объектов в архитектуре документа

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

Таблица 2-1 суммирует архитектуру объектов и требования подкласса основанного на документе приложения.

Необходимо разделить NSWindowController на подклассы

Даже если бы Ваш документ имеет только одно окно, это может быть достаточно сложно, что требуется разделить часть логики в уровне контроллера для имения контроллера представления, а также объекта контроллера модели. В этом случае необходимо разделить на подклассы NSWindowController а также NSDocument. Таким образом можно добавить специальные знания уровня представления приложения, что контроллер окна ответственен за управление. Любые выходы и действия и любое другое поведение, которое является определенным для управления пользовательским интерфейсом, входят NSWindowController подкласс. Специально для объемных приложений разделение режимов работы контроллера между двумя классами имеет много смысла. Эта стратегия позволяет Вам иметь документы, которые открыты, но не на экране, чтобы избежать иметь необходимость выделить память и другие ресурсы фронтэнда, который не может использоваться при некоторых обстоятельствах.

Причины разделить NSWindowController на подклассы

Если Ваш документ требует или позволяет многократные окна для единого документа, который является серьезным основанием разделить на подклассы NSWindowController. Например, программа CAD могла должна быть представить переднюю сторону, вершину, и виды сбоку, а также представленное 3D представление документа. Когда это делает, Вы могли бы хотеть иметь один или несколько подклассов NSWindowController управлять различными видами окон, в которых Ваш документ нужен, и таким образом, необходимо создать одного из каждого в makeWindowControllers.

Некоторые приложения нужны только в одном окне для документа, но хотят позволить пользователю создавать несколько копий окна для единого документа (иногда, это вызывают документом многократного представления) так, чтобы у пользователя могло быть каждое окно, прокрученное до различной позиции или выведенное на экран по-другому, такой как в различном масштабе. В этом случае, Ваш makeWindowControllers переопределение создало бы только один NSWindowController объект, и был бы командой меню или другим управлением, позволяющим пользователю создавать других.

Другая причина разделить на подклассы NSWindowController должен настроить Ваши заголовки окна документа. Настроить заголовок окна документа должным образом, подкласс NSWindowController и переопределение windowTitleForDocumentDisplayName:. Если Ваше приложение требует еще более глубокой настройки, переопределения synchronizeWindowTitleWithDocumentName.

Как разделить NSWindowController на подклассы

Как только Вы решили разделить на подклассы NSWindowController, необходимо изменить основанную на документе установку приложения по умолчанию. Во-первых, добавьте любые Интерфейсные выходы Разработчика и действия для пользовательского интерфейса Вашего документа к NSWindowController подкласс вместо к NSDocument подкласс. NSWindowController экземпляр подкласса должен быть Владельцем Файла для файла пера, потому что это создает лучшее разделение между связанной с представлением логикой и связанной с моделью логикой. Некоторые действия меню могут все еще быть реализованы в NSDocument подкласс. Например, Сохраните и Вернитесь, Документ реализован NSDocument, и Вы могли бы добавить другие собственные действия меню, такие как действие для создания новых представлений о документе.

Во-вторых, вместо переопределения windowNibName в Вашем NSDocument подкласс, переопределение makeWindowControllers. В makeWindowControllers, создайте по крайней мере один экземпляр своего пользовательского NSWindowController подкласс и использование addWindowController: добавить его к документу. Если для Вашего документа всегда нужны многократные контроллеры, создайте их всех здесь. Если документ может поддерживать многократные представления, но по умолчанию имеет один, создайте контроллер для представления по умолчанию здесь и обеспечьте пользовательские действия для создания других представлений.

Вы не должны вынуждать окна быть видимыми в makeWindowControllers. NSDocument делает это для Вас, если это является надлежащим.

Подкласс NSWindowController управляет файлами пера

NSWindowController объект ожидает быть сказанным что файл пера загрузиться (через initWithWindowNib... методы), потому что это - универсальная реализация поведения по умолчанию для всех контроллеров окна. Однако, когда Вы пишете подкласс NSWindowController, тот подкласс почти всегда разрабатывается для управления пользовательским интерфейсом, содержавшимся в определенном файле пера, и подкласс не работал бы с различным файлом пера. Это поэтому неудобно и подвержено ошибкам для instantiator подкласса для сообщения его который файл пера загрузиться.

Эта проблема решена путем переопределения init метод для вызова суперкласса initWithWindowNibName: метод с корректным именем пера. Тогда instantiators просто используют init, и контроллер имеет корректный файл пера. Можно также переопределить initWithWindowNib... методы для журналирования ошибки, как показано на рисунке 2-4, потому что никакой instantiator никогда не должен пытаться сказать подкласс который файл пера использовать. Это - хорошая идея для любого NSWindowController подкласс, разработанный для работы с определенным файлом пера для использования этого метода. Необходимо сделать иначе, только если Вы расширяете просто основную функциональность NSWindowController в Вашем подклассе и не связали ту функциональность ни с каким определенным файлом пера.

NSWindowController объект без связанного NSDocument объект полезен отдельно. NSWindowController может использоваться в качестве базового класса для вспомогательных контроллеров панели для получения использования его возможностей управления пером. Одно общее автономное использование NSWindowController подклассы как контроллеры для совместно используемых панелей тех, которые находят панели, инспекторов или предпочтительные панели. Например, демонстрационное использование приложения Эскиза NSWindowController подклассы для его различных вторичных панелей. В этом случае можно сделать NSWindowController подкласс, реализующий метод «совместно используемого экземпляра» для создания одноэлементного объекта контроллера окна. Например, Вы могли создать a PreferencesController подкласс с a sharedPreferenceController метод класса, создающий единственный экземпляр в первый раз, его вызывают и возвращает тот же самый экземпляр на всех последующих вызовах.

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