On 02/11/2009, at 10:46 PM, Ben Haller wrote:
There are a variable number of them per window, of a variable size and layout, depending upon data. (There are a variable number of objects being observed by the user, each of which gets a tableview, and each object has a variable set of properties being observed.)
Just for your interest, I have almost exactly this situation in my current app also (an object inspector, which handles multiple selections of arbitrary sets of objects). I do all the UI stuff in IB, with a very little bit of code to switch in the right views) according to the selection. Each controller is responsible for one type of object, and observes them using KVO, but otherwise drives the tables, etc using classic datasource/delegate type stuff, not bindings (though bindings would work here also, it's just that this code design predates bindings).
In my case I do some work on the selection I'm handed to work out what combination of views I need, and using a naming convention this returns the appropriate outlet ivars which are connected in IB to the various controllers, each of which in turn connects to a view which in turn host the relevant controls including tables. The whole lot is then swapped into the window in one fell swoop. It works great, and retains the distinct advantage that I can build all my UI in IB. The nib is a little complex, in that it contains all the controllers and views for the whole interface, so it's quite large, but even so I've never noticed it taking any time to load.
It never occurred to me to crack this problem by coding the UI, and I've never had cause to regret doing it this way. The "complicated bit" of working out what to do and swapping in the right controllers/ views is just a few methods - maybe 30-50 lines of code tops.
I'm not trying to show off - I just think that most reasons for not using IB turn out to be misguided, and this is just to show that there are real-world examples of what you're doing that are built using IB in the usual way. I'd strongly recommend it.
--Graham _______________________________________________ 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
