Re: Sharing a Bindings Controller between nibs
Re: Sharing a Bindings Controller between nibs
- Subject: Re: Sharing a Bindings Controller between nibs
- From: Ron Lue-Sang <email@hidden>
- Date: Fri, 17 Oct 2008 18:52:41 -0700
On Oct 14, 2008, at 4:06 PM, Graham Cox wrote:
On 15 Oct 2008, at 9:30 am, Citizen wrote:
I have a master-detail interface, where the Detail interface is in
a separate nib from the main Master interface (so that different
Detail interfaces can be swapped in).
The main Master interface nib contains an NSTreeController which is
used to display an iTunes like source list.
But I can't help feeling that there must be a better way of doing
this? Any suggestions?
To my mind it doesn't make sense to have each detail interface in a
separate nib. The interface unit is the whole collection of views
and parts that make it up, and these should be in the same nib.
Doing that will simplify this in every way.
Having separate views for each detail is fine, but then your
controller has to manage swapping them in and out. Even simpler
might be using a tabless view to embed them in and simply switch
tabs. That's what I do in a few M/D interfaces and it's very easy to
set up and works a treat.
--Graham
I'm gonna disagree with Graham on this one. I totally dig putting
separate views in separate nibs. I can't stand working with tabless
tabviews. This is partly a personal preference and partly a per
application variable, but I also don't like the idea of loading a
bunch of views if the user may not touch all of them. And I'd argue
that using separate nibs for separate views encourages better design
since you have to think things out – like you're doing here – to make
sure your design makes sense for all the detail views your building.
Then there's opportunity to reuse the same detail view in other parts
of the app, again, depending on your final design and app constraints.
Maybe I can start a flame war?
Anyway, if you want to go down my path of madness – there's lemonade
at the end! – I'd suggest binding to or observing the treeController's
selectedObjects property. So you'd still have an outlet to the
treecontroller in your MasterViewController. And then when it's set…
- (void)setTreeController:(NSTreeController *)controller {
// unbind from or stop observing the old controller
// bind to or start observing the new controller
[self bind:@"masterControllerSelectedObjects" toObject:TreeController
withKeyPath:@"selectedObjects" options:nil];
// and do the regular ivar maintenance.
// Note that you you don't have to do retains here if you're binding
to the treeController. The bind: retains the thing you're binding to.
// If you're just observing, then you'll need to do memory management
yourself. Unless you're using GC =)
}
And then you'd have an accessor in your MasterViewController which
returns the selectedObjects you were assigned from the treeController.
Now your detailControllers can either take the masterViewController as
a delegate, or just be assigned the selectedObjects when loaded or
when the selection changes.
Note, that I'm saying specifically to use selectedObjects here since
that's usually what you'll end up wanting in a true master/detail UI.
This way you can handle multiple selection in the detailUI by showing
multiple editors – one per selectedObject – or something.
Why, then shouldn't you just hook up the long keyPath from the
detailView to the treeController?
That would mean that the treeController owns the selection,
conceptually, for your app. I think you really want that maintained by
your mainViewController. Then you can save it and restore it, get
selections from other UI or enforce non-empty selection or override
selection or morph the selection or generate a selection at random
with a timer or from the internet, or whatever.
--------------------------
RONZILLA
_______________________________________________
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