On Feb 3, 2009, at 18:29, Luc Vandal wrote:
A1 = customers array with a to-many relationship to invoices
A2 = invoices array with a relationship to customers
Bindings set in IB as Content Set -> Customers.selection.invoices
with invoices as the model key path.
I understand that calling addObject directly is a KVO no-no and that
I need to get a NSMutableArray from my array controller and alter
it. But how do I know what key is related to the array? I tried
calling:
NSMutableArray *a = [invoiceArrayController
mutableArrayValueForKey:@"invoices"];
but I get this error:
[<NSArrayController 0x144b00> valueForUndefinedKey:]: this class is
not key value coding-compliant for the key invoices.
Also tried:
NSMutableArray *a = [invoiceArrayController
mutableArrayValueForKeyPath:@"Customers.selection.invoices"]; with
no success.
In the documentation, it says that 'key' is the name of an ordered
to-many relationship.
I did find documentation about this but it's lacking examples and
I'm confused. Could anyone explain or direct me to an example? It
seems that this is a common trap when starting to work with Core
Data but I've yet to find something clear to figure this out!
Yes, there's some confusion here.
First, you don't invoke mutableArrayValueForKey on a
NSArrayController. It's *already* a kind of array proxy, and it
already does things KVO-compliantly. The NSArrayController is not part
of the data model, it's really part of the user interface.
You use mutableArrayValueForKey when your data model contains an array
that you want to change KVO-compliantly. One reason for doing that is
to make sure that a NSArrayController connected to the data model
"sees" changes you make to the data model.
However, when your data model is Core Data based, the connection to a
NSArrayController is a bit more complicated. There are no arrays in
the data model unless you choose to provide them. (Relationships are
modelled as sets, not arrays. Core Data fetch operations return
arrays, but they're not exposed to the NSArrayController unless you
arrange to do so via the model's controller -- usually a
NSPersistentDocument or NSWindowController subclass acting as the NIB
file's owner.)
The confusing part is that NSArrayController has a convenience method
addObject which updates your data model for you, in a KVO-compliant
and Core-Data-compatible manner when appropriate. (The details depend
on the way the NSArrayController is configured. It may end up calling
[[... mutableArrayValueForKey:] addObject:], [[...
mutableSetValueForKey:] addObject:] or even [NSEntity
insertNewObjectForEntityForName:inManagedObjectContext:].) The
convenience method is convenient, but using it means that your code
has to know that there *is* a NSArrayController, which slightly
pollutes your data model or its data model controller with information
about the user interface. (Though sometimes you can't, or don't want
to, avoid that.)
Note that the main purpose of NSArrayController is to support bindings
between user interface elements and a data model. That's already a
level of complexity above plain old KVO notifications and observers.
When a NSArrayController is configured for use with a Core Data data
model, its behavior is even more complex. That's why it's often
recommended that you get really familiar with using bindings with a
non-Core-Data data model before you jump into Core Data.
Have you worked through:
http://developer.apple.com/documentation/Cocoa/Conceptual/NSPersistentDocumentTutorial/00_Introduction/chapter_1_section_1.html
yet?
_______________________________________________
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
