On 25 May 2008, at 5:15 pm, Johnny Lundy wrote:
And, if I don't understand something, I will ask why. This is not
magic - there is actual computer code behind that File's Owner
concept, and it is deterministic, not vague, not abstract, not a
philosophical enigma, not random, not ambiguous. If I had the source
code I could see what it does.
Despite teaching OB/GYN for 17 years, this is why computer science
is always my main interest. I've written firmware before we called
it firmware. I have never NOT been able to grasp something until
this and bindings. Aaron says lots of people have trouble
understanding File's Owner, so I can only conclude that it's the
documentation, or lack thereof.
Here's my simple-minded mental model of File's Owner.
1. A nib is a file. File's Owner is thus the nib's "owner". An owner
is any object that agrees to act as a manager for some other objects.
2. A nib is also, from another point-of-view, a pre-built box of
objects (pre-built by you, using Interface Builder).
3. Inside the box, objects can only connect to each other - it's a
closed system, so they are useless to the outside world, unless you
have a "connector" or "opening" or "port" (pick your own metaphor)
into and out of the box. File's Owner is that opening.
4. When the nib is loaded by some code (either some you've written or
indirectly by other parts of Cocoa), the owner object is supplied by
this code. All the connections made in IB to File's Owner are switched
over to the identically named outlets and action methods defined in
the real owner object. The icon you see labelled "File's Owner" in IB
is just a pretend object - the real one is substituted for it when the
nib is loaded, and that's all. To use a technical term, it's a proxy.
It's not magic - when the nib is loaded some code simply iterates
through the list of outlets and actions, finds the same ones in the
real object and copies the various pointers and selectors that point
both into the box (outlets) and out of the box (actions) to where they
need to be to actually function.
That really is the top and bottom of it. I think you're confusing
yourself by trying to square this with MVC and Bindings and other
things. They are not related, except in so far as being a real object
that you supply, File's Owner has to fit into the rest of the design
*as well* as performing this duty as the I/O port into the box (nib),
but that additional responsibility is of no concern to the nib or the
nib loading code.
The other thing that may be confusing you is that some example code
(like the Currency Converter you mention, though I'm not familiar with
it so I may be wrong) take the convenience of nibs a bit further to
cut down on the amount of code you need to write to understand the
point of the tutorial. Many tutorials are like this - they are often
aimed at demonstrating one specific thing, and take short cuts or
exhibit poor code practices in other areas unrelated to their main
point to save time. So, since a nib file is just a box of pre-built
objects, they can be any sort of object, including those that in a
better-written app shouldn't really be there, like model objects.
Whether a nib is (ab)used like this has no bearing on the meaning of
File's Owner, which is only the opening into the box *and nothing
more* in the context of the nib itself.
hth,
G.
_______________________________________________
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 [EMAIL PROTECTED]
