Re: File's Owner
Re: File's Owner
- Subject: Re: File's Owner
- From: dream cat7 <email@hidden>
- Date: Tue, 27 May 2008 02:24:32 +0100
So, a newbie's first exposure to File's Owner suggests that there's
a right answer to what File's Owner needs to be, but the
documentation (along with quite a number of the explanations in this
thread) insists that File's Owner can be whatever you want it to be.
Unless you clear up that *apparent* contradiction first, you can
lucidly explain File's Owner till you're blue in the face without
shedding any light whatsoever.
What about if everybody called it NibOwner instead ? Wouldn't that be
a lot clearer?
( from discussions earlier on )
"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.
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."
As a new developer I would have found that immediately more intuitive.
If the first time i opened up Interface builder I had an Icon which
allowed me to make connections to NibOwner. Using the term NibOwner is
far less ambiguous. It also promotes the wider context in which there
may be multiple nib files, or the fact the NibOwner can be re-assigned.
When you hear "file's owner" it tends to infer something more rigid
(like fixed in the filesystem). Like if the file's owner were the
application Bundle, or the User account (strictly speaking a file's
owner is actually a unix account name).
With no other point of reference then using the files owner object
seems irrelevant. Clicking on most of the tabs in the Inspector shows
"Not applicable" and a stretch not to conclude that it is rather
ambiguous object used infrequently for some niche purpose. Of course
it isn't a niche object at all, but a rather important one. However a
newbie who is learning Cocoa wont know that until they have read a
whole host of convoluted explainations. So i have to agree entirely
with these comment that it is a challenge to explain those words,
which must be an artefact of old Project Builder days stretching back...
Just to file a bug report with Apple: "File's owner" --> "Nib owner".
It gets my vote. Any objections ?
Finally we have also got some very good descriptions here about how to
make application code. Specifically the best way to partition the
cocoa classes and and connect them sensibly into a Model-View-
Controller. For those already keeping up theres no need to read on...
But this has proven to be a very useful dicussion so I would just like
to summarize some of the high - points.
>>>
" if you want to use your own
NSWindowController, often times you'll make the owner of the NIB the
NSWindowController itself, and if you need to get to the document you
can do so by going backwards through the NSWindowController subclass."
>>>
"I have since realized that I need to just make a separate class for
the model objects in Xcode (what I was doing, without realizing it,
was having my one class actually be the app controller as well as
the Model). Then just flat-out explicitly instantiate that class in
the App Controller code. Now I have a name for the Model class'
instance.
Then in the bindings for my View Object, I can bind it to my
NSArrayController's "selection" binding and set the model key path
to myModelInstance.myModelKeyName.
Took about a month of 16-hour days to get that down."
>>>
"Normally your model objects would be created in code that didn't
care about NIBs or any UI objects. Then you would have a few NIBs
that deal with different aspects of your application and they have
to access the shared model objects (shared amongst all NIBs). How
would the controllers in these NIBs access the model? Via one of the
proxy objects. Which one (Application or File's Owner) depends on
whether the model is a global resource or something specific like a
document. It also depends on the NIB and what it expects its owner
to be."
>>>
"In a real application of any substance you'd likely create your
model object dynamically (from saved data or a new state which you
intend to be able to save and load in the future).
In this _specific_ example (which is what that last sentence says)
the model object is being instantiated in the nib. This is because
the creation of the model object isn't what the example is
attempting to show... it's the connections between the objects and
creating them in IB."
>>>
My NSArrayControllers can be bound to model objects without
anything going through File's Owner.
"Really? That implies that your model is contained within the nib,
which is not how MVC is supposed to work. The nib should contain
the V (View) and possibly C (Controller) parts of MVC, but it should
not contain the M (Model). One of the points of separating Model
from View from Controller is that you can have multiple different
views on the same model. Imagine an application which represents a
set of numbers in one window in a table and in another window in a
graph. These two windows can (and probably should) be described in
separate nibs, and the model should live in neither. It should be
instantiated in code somewhere else in your application, or managed
with Core Data, etc. File's Owner would be needed to connect the
views and controllers in the nibs to the model."
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden