Создание интерфейса инспектора для произвольных базовых данных - PullRequest
4 голосов
/ 22 августа 2011

У меня есть приложение, в котором нужно хранить «стопку» редактируемых объектов, которая будет отображаться в одном пользовательском представлении.Каждый из этих объектов имеет различные параметры, которые должен редактировать пользователь.

Я смоделировал различные типы объектов, которые могут появляться в стеке как объекты базовых данных (технически они все являются дочерними объектами родительского объекта).сущности, но это не имеет отношения к вопросу).

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

До сих пор я рассмотрел следующее (RKStackObject является подклассом NSManagedObject):

  1. Уникальный NSViewControllerподкласс для каждого инспектора, для которого representedObject установлено значение RKStackObject и которое загружает перо, содержащее привязки, в representedObject.Главный контроллер выполняет загрузку различных контроллеров представления и связывает их с представленными ими объектами в стеке.

    Недостаток этого метода состоит в том, что для него требуется несколько классов на один объект стека, что может стать громоздким из-за большого количестватипов объектов.Он также опирается на внешний контроллер для управления всеми объектами.Основное преимущество заключается в том, что с помощью Interface Builder легко создавать пользовательские инспекторы.

  2. Интерфейс, аналогичный CIFilter Дополнениям комплекта изображений метод viewForUIConfiguration:excludedKeys,что позволяет объектам RKStackObject возвращать свои собственные представления инспекторов с уже имеющимися привязками.По умолчанию возвращается стандартное представление, но его можно изменить с помощью протокола.

    Это выглядит чище, но мне также кажется, что это перегружает объект модели большим количеством кода контроллера.Может быть, это нормально?

Есть ли другие предложения о том, как это сделать?

Другая проблема, с которой я столкнулся, заключается в том, что существует также некоторый пользовательский код рисования, связанный стип объекта в стеке.Я не уверен, куда это должно пойти, кажется неправильным помещать его в подкласс NSManagedObject, но создание специального объекта «controller», просто для хранения кода чертежа, также кажется излишним.Код чертежа реализован в виде протокола на главном виде.Возможно, этот код может быть просто сохранен в категории объекта модели, чем-то вроде NSString дополнений AppKit для рисования и т. Д.

Я немного обеспокоен тем, что создаю объекты модели, которые имеют обапросмотреть код (для чертежа) и код контроллера (для инспектора), который, казалось бы, нарушил всю парадигму MVC.

Есть мысли о том, как лучше организовать этот проект?

...