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: Mon, 24 Mar 2008 10:57:45 -0400
Adam,
I had been using those very NSTreeController extensions in addition to my
proxy classes. They use undocumented APIs (as far as I can tell), and broke
when I updated my project to 10.5 only, because (I think) NSTreeController
adopted a public API (NSTreeNode) in place of what the extensions were based
on.
In principal, I'd be happy to share code that I think would be helpful, but
my proxy classes are loaded with baggage I need to remove and I've had to
table my private project in favor of the one that pays the bills. ;-)
Doug K;
On Mon, Mar 24, 2008 at 1:10 AM, Adam Gerson <email@hidden> wrote:
> Hey Doug,
>
> Thanks so much for your help. Un checking "Raises For Not Applicable
> Keys" did the trick.
>
> Take a look at DragAndDropOutlineEdit.zip
>
> http://homepage.mac.com/matthol2/cocoa/page2/page2.html
>
> The author has an NSTreeController extension that makes accessing the
> "real" objects much easier.
>
> Would you be willing to share one of you proxy object classes as an
> example?
>
> Adam
>
>
> > 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