On Jan 16, 2009, at 06:38, Rick Hoge wrote:
I tried something like the code shown below in a custom "Project"
class, for the project entity:
-(NSMutableSet*)children {
return [NSMutableSet setWithObjects:
[self mutableSetValueForKey:@"targets"],
[self mutableSetValueForKey:@"bookmarks"],
nil];
}
but I get the error message
2009-01-16 09:35:02.047 004 ProjectProto[83363:10b]
[<_NSNotifyingWrapperMutableSet 0x1057dd0>
addObserver:forKeyPath:options:context:] is not supported. Key path:
children
The problem with this is that your root object is saying it has 2
children, but the child objects are of class NSSet (actually, a set
proxy that has the identical interface) and so *they* don't respond to
"children" as they need to.
One answer is to create two new Core Data entities that *do* have a
"children" method, which retrieve the appropriate information from the
parent object. Or, once you'd done that, it might turn out to be more
convenient to move some of the root properties into the appropriate
child.
Another answer is to create an entirely separate hierarchy of non-Core-
Data objects that represent what is to appear in the outline view, and
have these function as proxies exposing just the properties you need
to show in the outline view.
BTW, although it has nothing to do with your problem, I'll point out
that "entity" doesn't mean "object" in Core-Data-speak. From the Core
Data programming guide:
entity
An abstract description of a data-bearing object equivalent to
“model” in the Model-View-Controller design pattern. The components
of an entity are called attributes, and the references to other
models are called relationships. Together, attributes and
relationships are known as properties. Entities are to managed
objects what Class is to instances of a class, or—using a database
analogy—entities are to managed objects what tables are to rows.
Perhaps "entity" wasn't the happiest choice of terminology, but I
mention it because it's often misused on this list, and Core Data is
difficult enough to talk about without getting to cross purposes over
terminology. :)
_______________________________________________
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
