Re: Canonical way of loading compound UI components from a NIB into some other UI?
Re: Canonical way of loading compound UI components from a NIB into some other UI?
- Subject: Re: Canonical way of loading compound UI components from a NIB into some other UI?
- From: Ricky Sharp <email@hidden>
- Date: Wed, 5 Dec 2007 17:37:30 -0600
On Dec 5, 2007, at 4:45 PM, Luke Evans wrote:
I've been scratching around to find the _right_ way of loading some
compound UI from one Nib into a view within another Nib. In other
words, I wish to define a compound view hierarchy as a 'custom
control' and then load this into the location represented by a
custom view in some other Nib, such as in a window.
So, lets say I have a my compound control hierarchy, consisting of a
scroll view at the top, which then contains a number of other
views. These are all stored in a Nib called ScrollingControls.nib.
Now, in my main Nib, I might have a NSWindow and I wish to place a
custom view within this window that will define the location of the
root view in my ScrollingControls hierarchy.
I have something similar in my apps. I have a single window in my
main nib. I then have multiple nibs which contains the full UI of a
particular "screen" in an NSPanel**. As the user moves from screen to
screen, I load up the appropriate nib, and set the window's content
view to be the content view of the NSPanel. The content view of the
panel is always a single instance of a custom container view (that
forms the root of the contained UI). Each nib also has a subclass of
a base controller class that manages everything with that particular UI.
You could definitely create a similar nib to contain a re-usable UI
that can be dropped in anywhere. In my case though, only a single
instance of the UI is ever on-screen at any given time. It sounds
like you need to load up multiple instances? Thus, my approach may
not work, or may need to be modified.
** It's not necessary to put your stuff in a panel; you can drag in a
view itself and embed your UI in it. That view will then be directly
used as the window's content view (or whatever content view you
want). In my specific case, I had need to have the view sit inside an
NSPanel instance for other reasons.
It seems to me that there are a number of gotchas, or at least
'inelegance' (or maybe just work!!) in how I would have to go about
this.
1. If I choose to make the placeholder custom control in my NSWindow
into an actual instance of the some top-level view class in my
ScrollingControls (i.e. in this case it would be natural for this to
be the scroll view), then I have to make this root view in
ScrollingControls be a special case - it would need to be a subclass
of NSScrollView that knows how to load the remaining part of the
compound view from a Nib file - yet this view itself would NOT
reside in this Nib. This has the right encapsulation (the subtree
that is loaded is the business of the root of the 'control' itself),
but I dislike the asymmetry of having to have the top level view
exist outside of the rest of Nib that defines the complete view
hierarchy I want.
Not sure what you mean here about having to have a subclass to "load
the remaining part of the compound view".
2. If I choose to have ALL the ScrollingControls view hierarchy,
including the top level NSScrollView exist in ScrollingControls.nib,
then I cannot see how to elegantly make the placeholder custom view
in the NSWindow automatically load the view subtree from
ScrollingControls.nib and replace the placeholder view. There are
certainly various workarounds that come to mind, such as having a
special NSView subclass in the NSWindow, which does the requisite
loading of the entire ScrollingControls view tree, and that then
performs a "replaceSubview", to substitute itself with the intended
top of the view hierarchy at that point (i.e. the NSScrollView).
This sort of thing seems somewhat awkward however.
Still not sure what you mean here about loading. To provide further
details of my multiple-nib approach above...
In my application controller class, I have a generic "loadScreen"
method. It takes a name and I dynamically build a nib name from it.
I then create an instance of a window controller subclass and
ultimately initialize it with initWithWindowNibName:owner:
Note that this window control subclass approach may not be needed. I
needed to do this in order to correctly deal with top-level objects in
the nib. If you need to go this route, I can point you to some old
threads that have more detail.
So, in a nutshell, I'm looking for the canonical pattern for loading
a view hierarchy from a Nib into a placeholder custom view, without
having to add an extra (essentially spurious) view layer to do this
loading. I've hunted around for some code to demonstrate the right
pattern for this, but most examples deal with loading a single
custom view (without an attendant hierarchy) .
At this point, it seems to me that I cannot avoid having to break
the symmetry, and having the root control that is referenced from
the placeholder custom control be different to the rest of the
hierarchy loaded from Nib (which is what it has to control in it's
awakeFromNib). Yet, it also seems to me that a number of items in
the Interface Builder palette are compound (such as the
NSCollectionView), and this is the behaviour that I'd like - to be
simply able to include a subtree of views directly into some UI.
Maybe there's some jiggery-pokery going on in the case of Interface
Builder plug-ins to achieve this, and I certainly don't want to have
to go to the bother of creating a plug-in to achieve what I want.
I'm hoping I'm missing something simple here!
___________________________________________________________
Ricky A. Sharp mailto:email@hidden
Instant Interactive(tm) http://www.instantinteractive.com
_______________________________________________
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