If I understand correctly: * You want to have a single general-purpose model class (what you are calling the "object") for which different object types might have different sets of attributes. Kind of like a dictionary or an NSManagedObject.
* You'd like to use xib files to serve as attribute specification files, using the fact that they already implicitly know what attributes that type of object has by virtue of the UI controls that are in that inspector. * You'd like a single general-purpose controller class that knows how to derive the attribute specification from the xib file, and interacts with your general-purpose model class accordingly. * The object types have lots of attributes and/or there are lots of different types, so it's tedious to write boilerplate code every time you add an object type. First thought: you could use the NSMatrix hack I described earlier to construct the kind of xibs you want. It would let you map arbitrary strings to arbitrary objects in the xib. Second thought: you could use some sort of code generator, either Kevin Callahan's Accessorizer or a script you write yourself to help write model classes (and not try to have a single general-purpose model class). Third thought: in IB, you could assign bindings to all the UI components -- this seems a natural thing to do regardless -- and somewhere in your code you could iterate through all subviews of that inspector view and derive attribute names by parsing the bindings. This is assuming it's possible to ask a view what its bindings are, which I don't know how to do offhand. Anyway, a text field might have a binding "inspectedObject.title" and that's how you'd know there's a "title" attribute. --Andy On Friday, June 19, 2009, at 03:35PM, "Chilton Webb" <chil...@mac.com> wrote: >Hi, > >Here's why I'm asking. > >Right now I have an app that has a number of possibly different >'objects' in it. And I currently have a single inspector for all of >them. >When a new object is selected, the appropriate view for that object is >added to the inspector window. > >This is a basically okay design. > >The problem is that for any new object I add, I have to... >1) Add the object code, which contains all of the names of all of the >things I want in it >2) Add the inspector view controller code, which contains all of the >same names >3) Add the inspector view xib, which contains zero same names, so I >need to physically wire up all of the fields to things with the right >names. > >If I had a way of tagging the objects by name inside XCode, then I >could actually whittle this down to a single object file, that would >use the keys found on the objects themselves (title, settings, etc.) >as tags for saving/restoring their state from files, as well as >knowing what properties to change on the objects. This would eliminate >over 80% of the code I currently have to write, and duplicate, for >each object. And those object files are HUGE. > >This would also mean that to use one of these objects in another app, >all the other app would need would be a fairly generic interface to >the object. > >-Chilton _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
