У меня есть приложение, в котором нужно хранить «стопку» редактируемых объектов, которая будет отображаться в одном пользовательском представлении.Каждый из этих объектов имеет различные параметры, которые должен редактировать пользователь.
Я смоделировал различные типы объектов, которые могут появляться в стеке как объекты базовых данных (технически они все являются дочерними объектами родительского объекта).сущности, но это не имеет отношения к вопросу).
Я хочу предоставить уникальную панель инспектора для каждого типа объектов в стеке, но я немного застрял в том, что лучшеметод для этого.
До сих пор я рассмотрел следующее (RKStackObject
является подклассом NSManagedObject
):
Уникальный NSViewController
подкласс для каждого инспектора, для которого representedObject
установлено значение RKStackObject
и которое загружает перо, содержащее привязки, в representedObject
.Главный контроллер выполняет загрузку различных контроллеров представления и связывает их с представленными ими объектами в стеке.
Недостаток этого метода состоит в том, что для него требуется несколько классов на один объект стека, что может стать громоздким из-за большого количестватипов объектов.Он также опирается на внешний контроллер для управления всеми объектами.Основное преимущество заключается в том, что с помощью Interface Builder легко создавать пользовательские инспекторы.
Интерфейс, аналогичный CIFilter
Дополнениям комплекта изображений метод viewForUIConfiguration:excludedKeys
,что позволяет объектам RKStackObject
возвращать свои собственные представления инспекторов с уже имеющимися привязками.По умолчанию возвращается стандартное представление, но его можно изменить с помощью протокола.
Это выглядит чище, но мне также кажется, что это перегружает объект модели большим количеством кода контроллера.Может быть, это нормально?
Есть ли другие предложения о том, как это сделать?
Другая проблема, с которой я столкнулся, заключается в том, что существует также некоторый пользовательский код рисования, связанный стип объекта в стеке.Я не уверен, куда это должно пойти, кажется неправильным помещать его в подкласс NSManagedObject
, но создание специального объекта «controller», просто для хранения кода чертежа, также кажется излишним.Код чертежа реализован в виде протокола на главном виде.Возможно, этот код может быть просто сохранен в категории объекта модели, чем-то вроде NSString
дополнений AppKit для рисования и т. Д.
Я немного обеспокоен тем, что создаю объекты модели, которые имеют обапросмотреть код (для чертежа) и код контроллера (для инспектора), который, казалось бы, нарушил всю парадигму MVC.
Есть мысли о том, как лучше организовать этот проект?