Re: NSTreeController / CoreData still broken in 10.5?
Re: NSTreeController / CoreData still broken in 10.5?
- Subject: Re: NSTreeController / CoreData still broken in 10.5?
- From: "Doug Knowles" <email@hidden>
- Date: Sun, 23 Mar 2008 21:55:10 -0400
Hi, Adam,
I hesitate to present myself as an expert, but I've probably contributed to
the perception of broken-ness in 10.4, and I've received an awful lot of
help on this list, so I'll try to pay it forward:
My biggest gripe about outline views and tree controllers in 10.4 was that
it was difficult (impossible) to correlate items in the outline view with
their corresponding objects in the model in a (fully) supported way. This
is much better in 10.5; I haven't removed all the workarounds from my code
yet, but I am confident that I could and I will before I'm done. (I'm
converting my app to 10.5-only, which simplifies things.)
I have been using mixed entities in an outline view for a while, and I
haven't found it to be a particular problem, even under 10.4.
NSTreeController does want a specific entity type if it's using Entity mode.
It's certainly the case that entities in the tree need to implement the
designated "children" and (optional) "Leaf" and "Count" keypaths, but they
can be different sub-entities of the designated entity type if its feasible
to go that route.
If you bind an outline column to an property of the objects in the tree, and
some of your entities don't implement the property, you probably want to
turn off the "Raises [exception] For Not Applicable Keys" flag on that
binding.
(As far as I know, I don't think the column bindings care if the entities
that it references a "fubar" property from are all from the same class, or
derive from a common class; it the entity implements "fubar", the binding
uses it.)
In my case, I found it advantageous for a variety of different reasons to
put the tree controller in Class mode and create "proxy" objects (that all
derive from a base class that is the designated class for the tree
controller). The benefits of doing this is that my proxy objects can
implement any properties or behaviors that exist for the presentation in the
UI, independently of the Core Data entities that implement my model. So,
for example, my proxy objects implement a "displayName" property used in my
presentation, and derive those values in an entity-specific way without
pushing that presentation implementation down into my model objects.
The proxy approach is a little more work, but it's not all that bad if you
remember to "use the Force" (the wonderful-ness of key-value observing).
I hope this helps; if I can clarify please let me know.
Doug K;
On Sun, Mar 23, 2008 at 7:55 PM, Adam Gerson <email@hidden> wrote:
> A general question:
>
> I have read a lot of discouraging posts on this list and out on the
> blogs about the trio of NSTreeController, NSOutlIneView and CoreData.
> Most of them come from the 10.4 era. Under 10.5 is this something that
> is working better now?
>
> A specific question:
> A lot of the NSTreeController, NSOutlIneView and CoreData example
> projects use a single entity that can be both a child and a parent of
> itself. If I want to model parent and child entities that have a
> completely different set of attributes (one is a group of objects, the
> other is the objects themselves) am I better of not using
> NSTreeController and CoreData? One problem I have already run into is
> that when you bind your entire OutlineView column to a
> NSTreeController entity it wants the parents and children to all have
> the same attributes.
>
> Adam
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> 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:
>
> This email sent to email@hidden
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden