On Jun 6, 2010, at 4:34 AM, Jean-François Brouillet wrote:

> It would be more effective to just answer "No. What you say you want is not 
> supported" rather than missing the point.

I did say that.  I also tried to give you the conceptual grounding so that you 
could understand why.


> This controller is my "root controller" I want and need exactly ONE such 
> controller.
> 
> In my XIB file I then create one of those UIViewImage "proxy object" (yes, 
> just a template) and in that template I say: BTW the image (UIImage, another 
> "proxy/template") I want is: xyz.png.
> 
> I then connect my titleView to that "proxy".

You are misunderstanding my use of the word "proxy".  You are incorrectly 
combining it with my use of the word "template".  I did not mean to suggest 
that each thing in a NIB is a proxy (or a template).

The NIB as a whole is a template for an object graph.

Most of the things in a NIB are "freeze-dried" objects that get reconstituted 
each time the NIB is loaded.  _Some_ things in a NIB, though, are not 
"freeze-dried" objects.  They are placeholders in the object graph.  When a NIB 
is loaded, an owner object is passed in to the loading machinery.  That 
pre-existing object is plugged into the new object graph in the "hole" 
represented by File's Owner in the NIB.  Also, the application object is 
plugged into the hole represented by Application in the NIB.  Neither the 
application object nor the owner object are "in" the NIB.  Only proxies / 
stand-ins / placeholders are there in the NIB editing process to allow you to 
establish connections and bindings to those objects even though they aren't in 
the NIB.

My point is that your view controller is not in the NIB.  It should be what 
loads the NIB, thus it has to pre-exist the NIB.  It passes itself in as the 
owner of the NIB, thus allowing for the new object graph created by loading the 
NIB to be connected to the pre-existing object graph of the application.

Any connection from the objects in the NIB to any other objects must be formed 
by such connections to the File's Owner or Application placeholders, or by 
bindings to/through their properties.


> Now in *another* nib file I have *another* controller

Again, does the second NIB _contain_ the other controller or merely reference 
it via its File's Owner placeholder?  Generally speaking, it should just 
reference it.

> and I wanted to tell it: "BTW the image you want is in nib file 1, object id 
> 789"

That doesn't designate a unique object.  A NIB may be loaded multiple times 
during the lifetime of an application.  Each time, a different set of objects 
is created.  In order for the designation to be specific to a single object, 
you'd have to say "nib file 1, object id 789, for NIB load 7" (or whatever).  
Even that doesn't really work, since the NIB-loading machinery doesn't give you 
direct access to the full object graph.  If you were to get into the details of 
the NIB-loading classes, you'd see they can return an array of the top-level 
objects from the NIB, but not any deeper objects.  The correct way to get at a 
specific object within the NIB is to declare an outlet on the File's Owner 
class and connect that to the object.  (In theory, you could try to traverse 
the object graph from the top-level objects, but you have very little to go on 
to find any specific object.  The names and IDs that you see in IB are not 
meaningful anywhere else and are not available to you in the loaded object 
graph.)

What you have said also smacks of using the View layer as though it were Model 
state.

If the UIImage is indeed part of the model, it shouldn't reside in the NIB.  It 
should reside in your model layer and your views would obtain it from their 
controller.

If the UIImage is itself not a part of the model, then perhaps the particular 
image name being used is.  In that case, each NIB would have a separate 
UIImage, but each might bind its image name to a property of the controller.


> The consensus here seems to be that this is not possible, but please, stop 
> telling me that it doesn't make sense.

Except it doesn't make sense.  Given what NIBs are -- that is, given my point 
about how a (NIB file name, object ID) pair doesn't uniquely designate an 
object -- there is no conceivable way to implement cross-NIB connections.  If 
that differs from "Spring" or whatever, then so be it.  NIBs aren't those.

> So, I've got the message, thank you, and I'm going to *programatically* share 
> that view either in the app delegate or the root view controller, whichever 
> way is cleanest.

You shouldn't be sharing views.  For one thing, a view can only be part of one 
view hierarchy at a time.  I think that attempting to share views is going to 
cause you no end of grief.

Multiple views may reflect shared model state, though.

Regards,
Ken

_______________________________________________

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

Reply via email to