Hi, there,
Maybe I'm simply confused or confusing the issue, but would it perhaps
make sense to store the tree controller's contents *not* within the
tree controller itself, but in an external array of "root" objects
whose children the tree controller can present?
This way, by binding this "root" array to the contentObject or
contentArray bindings (or whatnot), one can access the tree
controller's items without querying the tree controller itself, save
for perhaps sort descriptors or filter predicate information, and one
can avoid at times querying the outline view, too.
Once again, apologies if I'm missing something important. :)
Cheers,
Andrew
On Apr 5, 2008, at 12:34 PM, Doug Knowles wrote:
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 PROTECTED]>
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 PROTECTED]>
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 PROTECTED]>
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 (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/knowles.doug%40gmail.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
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/andrew.merenbach%40ucla.edu
This email sent to [EMAIL PROTECTED]
_______________________________________________
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 [EMAIL PROTECTED]
