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: Sat, 5 Apr 2008 15:34:15 -0400
Hi, Adam,
I've never tried to get the content back out of a tree controller; I usually
just walk the tree that I passed into setContent:. The disadvantage of the
hypothetical accessor you and Will (and I) would prefer to use is that the
objects won't necessarily be in the displayed order.
If you wanted to enumerate just the visible objects, you could enumerate an
outline view's rows, and get the representedObject of each row's item.
This, of course, would not address objects within collapsed tree nodes.
(Unless you expanded collapsed nodes to enumerate them, then collapsed them
back when you were done. I don't know if you can do this without
re-rendering the view, which would be visually annoying.)
Sorry I can't be of more help.
Doug K;
On Sat, Apr 5, 2008 at 2:33 PM, Adam Gerson <email@hidden> wrote:
> Hey Doug,
>
> I know under 10.5 I can use the treecontroller methods selectedObjects
> and representedObject to get at the real objects. However, this only
> gives me the selected object(s) or another single object. Do you know
> of a way for me to get all of the objects in the tree so I can loop
> over them?
>
> I am looking for the equivalent of arrangedObjects except one that
> returns the real objects. I know Will Shipley's post complains about
> this, but his extensions dont address it.
>
> - (id)arrangedObjects; // opaque root node representation of all
> displayed objects. This is just for binding to or passing around. At
> this time, developers should not make any assumption about what
> methods this object responds to.
>
> Thanks
> Adam
>
>
> On Sun, Mar 23, 2008 at 9:55 PM, Doug Knowles <email@hidden>
> wrote:
> > 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