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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
