site_archiver@lists.apple.com Delivered-To: cocoa-dev@lists.apple.com 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/CocoaBi...
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.projects.@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 bradgibbs@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/site_archiver%40lists.apple... This email sent to site_archiver@lists.apple.com