Yes, that's exactly it. Dual level master detail. For whatever reason, the part I just couldn't see in my head was how to wire up the second NSArrayController to accountsController.selection.items.
Thank you so much - just needed that little kick to get to the next step. Appreciate it. On Dec 28, 2009, at 7:38 PM, Quincey Morris wrote: > On Dec 28, 2009, at 16:19, Hunter Hillegas wrote: > >> I did read this page - but I'm not sure it does what I want because it's >> only 2/3rds of my interface. The master-detail explained there works fine >> for my items list and to display the selected item's properties but I need >> the list of items (the master in Apple's example) to be the result of >> another relationship (the accounts - each account can have zero to many >> items). So almost as master-master-detail, even though that's a terrible >> term. > > Actually, your items are the *detail* for the account, and then possibly the > master for another detail interface. > > So, let's say you have a NSTableView listing accounts, a second NSTableView > listing items in the accounts list's selection, and a set of text fields, etc > showing more details of the item(s) selected in the item list. > > The accounts list uses a NSArrayController whose content is bound to the > accounts (array if not Core Data, set if Core Data) in your data model. > > Columns in your accounts list would be bound to > accountsController.arrangedObjects.whateverAccountProperty. > > The items list uses a second NSArrayController whose content is bound to > accountsController.selection.items. This represents the items in the selected > account, or possibly in the selected accounts. (In NSControllerland, there's > really no distinction between a single object or multiple objects, until > later in the process -- each eventual UI element deals with the problem of > how to display multiple items. There's also an option somewhere that controls > how the items are merged if there are multiple selected accounts, but if your > items are unique to an account, the result would be the same.) > > Columns in your items list would be bound to > itemsController.arrangedObjects.whateverItemProperty. > > Item detail elements like text fields -- if you want them -- would be bound > to itemsController.selection.whateverItemProperty. Such user interface > elements would then display the value of the item selected in the items list. > If there are multiple items selected, then the binding options for multiple > values selections kick in. > > So your interface is not so much master-master-detail as dual-level > master-detail. > > There's probably an alternative way of approaching this, by programmatically > maintaining a fetch request for the items array controller, based on > monitoring the selection of the account array controller, but I can't think > of any obvious way to do this without writing code. (A few lines of code, but > code nevertheless.) Chaining array controllers, and using the arrangedObjects > or selection properties as appropriate, should allow you to design the > interface codelessly. > > Does that sound like what you need? There was a different tutorial that > explored some of this, but I can't find it any more. > > > _______________________________________________ > > 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/lists%40lastonepicked.com > > This email sent to li...@lastonepicked.com _______________________________________________ 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
