Thanks for the pointers, Quincey. I tried a few of the things you suggested, but settled on the filter predicate. I added my view controller for the projects detail view as an observer to self.selections.account. Each time the selected account changes, I set the filter predicate to filter the list of projects to show only the projects for the newly-selected account. Everything seems to be working fine, now.
Thanks again. Brad On Dec 30, 2009, at 12:44 PM, Quincey Morris wrote: > On Dec 30, 2009, at 10:12, Brad Gibbs wrote: > >> Account <--->>ProjectSite<--->>Project >> >> I'm trying to get the projects array controller to load all projects for the >> selected Account (so, all Projects for all ProjectSites). >> >> I've got an NSTableView listing accounts on the left, and view controllers >> to display detail table views to the right. One of the detail table views >> lists all ProjectSites for the selected Account. That's working fine. >> Another detail table view should list all Projects for the Account, but I >> can't get the Projects array controller to bind to the selected Account. >> These methods list all projects for the selected Account: >> >> NSLog(@"Projects for account are %@", [self.selections.account >> valueForKeyPath:@"projectSites.projects.displayName"]); >> NSLog(@"All projects for account are %@", [[self.selections.account >> allProjectsForAccount] valueForKey:@"displayName"]); >> >> But, I can't translate that into the proper ContentSet binding for the >> Projects AC. I've tried every combination I could think of, including: >> >> 1. creating an Object Controller for the selectedAccount and binding the >> Project's ContentSet to that controller with projectSites.projects >> 2. creating an Array Controller for the selectedAccount's ProjectSites and >> binding to that >> 3. creating a managedObject subclass for Project with a method that returns >> [self valueForKeyPath:@"projectSites.projects"] and binding the projects >> AC's contentSet to that property >> 4. using combinations of @distinctUnionOfSets > > Basically, there are two usual ways you use an array controller: > > 1. In "entity" mode, where its "contentSet" binding is bound to a Core Data > (set) property of a data model object. It's going to use *all* the objects of > the configured Core Data entity, unless you use a filter predicate or a fetch > predicate, or unless you actually use a transient property that you've coded > to fetch only some of the objects. > > You *could* use this for your projects list, but you'd have to write code to > maintain a suitable filter predicate or fetch predicate or transient > property, based on the selected account. > > 2. In "class" mode with a source array, where its "contentArray" binding is > bound to a non-Core Data (array) property of a data model object. It's up to > you to maintain that data model array property KVO-compliantly, or the > binding won't update reliably. > > See: > > > http://developer.apple.com/mac/library/documentation/Cocoa/Reference/CocoaBindingsRef/BindingsText/NSArrayController.html > > So I think you'll need to: > > -- bind accountsArrayController's "contentSet" binding to your data model > object's "accounts" property > > -- bind projectSitesArrayController's "contentArray" binding to > "accountsArrayController.selection.projectSites" > > -- bind projectsArrayController's "contentArray" binding to > "projectsitesarraycontroller.arrangedobjects.projec...@distinctunionofarrays" > (because you said all projects for the account, not all projects for the > selected sites) > > With these bindings (if I've got them right), only the first array controller > is in "entity" mode. So, you cannot use projectSitesArrayController or > projectsArrayController to create or delete objects directly. If you have "+" > and "-" buttons for them your interface, their action methods need to be in > (say) your document or window controller class, and you have to write code to > create suitable objects and relationships. > > Your references, above, to "selections" and "allProjectsForAccount" methods > suggest that you've been trying to solve the problem by adding custom > properties to your NSManagedObject custom subclasses. The problem *is* > solvable that way, but you have to be careful to distinguish non-Core Data > custom properties, which are arrays, from Core Data "custom" (i.e. transient) > properties, which are sets. And, you have to make sure you get KVO-compliance > right -- not always easy. And, when you're using Core Data you have to be > careful that you don't mess up undo using non-Core Data custom properties. > > > > _______________________________________________ > > 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/bradgibbs%40mac.com > > This email sent to bradgi...@mac.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
