On 2-Nov-09, at 9:26 AM, Graham Cox wrote:
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.
Yes, I certainly *could* put it into IB with this sort of a
design. I'm just not sure I see the point. Since I can have a
variable number of these tableviews in my window, from 0 to
arbitrarily many (well, depending on screen size limitations :->), I
would have to put the tableview into its own nib, not in my document
nib, and load that table nib however many times, and size and position
each tableview once its nib was loaded. I could have some of the
visible properties of the table set in the nib, instead of making the
corresponding calls in code; that seems like six of one, half a dozen
of the other. Apart from the fact that I just wasted all morning on a
digression caused by the fact that I'm doing it in code, I don't
really see the downside of doing it in code. ;->
Seriously, I think I actually prefer doing it in code. You could
instantiate all sorts of things in nibs; every time you call [class
alloc] you could have a nib with that object in it instead. Why don't
we do things this way? Because it's silly and excessively
complicated. Why do we ever put things into nibs, then? Because
particularly for UI objects and objects intimately associated with
them, configuring their visible properties is easier and more
intuitively done graphically. But in this case, almost none of the
visible properties of the tableview (size, position, number of
columns, number of rows...) are fixed at compile time, and so using a
nib doesn't buy much. And it makes a lot of the other configuration
of the table (custom data cell classes for each column, etc.) very
fiddly and annoying to work with compared to doing it in code, IMHO.
Usually I would agree with you; if someone said they were setting
up their whole window's content in code, as I am doing, that would be
a red flag. But here it just seems easier; the content is just too
dynamic. Call me crazy. :->
Ben Haller
Stick Software
_______________________________________________
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
