Creating an inspector UI for arbitrary Core Data entities

I have an app that needs to store a "stack" of editable objects, which will be displayed in a single custom view. Each of these objects has various parameters that must be editable by the user.

I have modelled the various types of objects that can appear in the stack as Core Data entities (technically they are all sub-entities of a parent entity, but that is not relevant to the question).

What I want to do is provide a unique inspector panel for each type of object in the stack, but I'm a bit stuck as to what the best method is for doing this.

So far I've considered the following (RKStackObject is a subclass of NSManagedObject):

1. A unique NSViewController subclass for each inspector, which has its representedObject set to the RKStackObject and which loads a nib containing bindings to the representedObject. A master controller takes care of loading the various view controllers and associating them with their represented objects in the stack.

   The disadvantage of this method is that it requires multiple classes per stack object, which could become unwieldy with a lot of object types. It also relies on an external controller to manage all the objects. The main advantage is that it is easy to create custom inspectors using Interface Builder.

2. An interface similar to the CIFilter Image Kit Additions method viewForUIConfiguration:excludedKeys, which lets the RKStackObject objects return their own inspector views with bindings already in place. By default, a standard view is returned but it can be modified via a protocol.

   This seems cleaner but it also seems to me that this is overloading the model object with a lot of controller code. Maybe this is OK?

Are there other suggestions for how to do this?

The other issue I have is that there is also some custom drawing code related to each type of object in the stack. I'm not sure where this should go, it seems wrong to put it in the subclass of NSManagedObject, but creating a special "controller" object just to hold the drawing code seems redundant also. The drawing code is implemented as a protocol on the main view. Perhaps this code could just be stored in a category on the model object, a bit like the NSString AppKit additions for drawing etc?

I'm a bit worried that I'm creating model objects that have both view code (for drawing) and controller code (for the inspector) which would seem to break the whole MVC paradigm开发者_高级运维.

Any thoughts on how I can best organize this project?