Re: Looking for a non-Core Data tree solution in Cocoa... is there one?
Re: Looking for a non-Core Data tree solution in Cocoa... is there one?
- Subject: Re: Looking for a non-Core Data tree solution in Cocoa... is there one?
- From: Chris Hanson <email@hidden>
- Date: Mon, 28 May 2007 05:29:20 -0700
On May 28, 2007, at 4:51 AM, Sam Stigler wrote:
I'm writing because I'm trying to use a tree (more specifically an
NSTreeController because it's the only tree class provided by Apple)
for the task of holding categories for an Amazon.com "browse" items
search (through their web service), but I'm really not finding it up
to the task: The methods provided just don't seem up to par with
their Java counterparts, which are what I've used before when I've
programatically manipulated trees.
It sounds like you're trying to use NSTreeController to represent a
tree, rather than as the controller for a tree of model objects that
you're presenting through some hierarchical view object.
After reading further, I see that I'm right. What were you referring
to as "Java counterparts" to NSTreeController?
I assume (and please, please correct me if I'm wrong) that this is
because NSTreeController is designed more with bindings in mind than
with programmatic manipulation in mind, but right now I'm trying to
use it mainly as an internal data structure that the user will
probably never see, and it's presenting me with all kinds of
obstacles: Seemingly-basic tasks having to do with adding a child
to an object in the tree are turning into marathons because since
NSTreeController doesn't have a containsObject method, nor a method
to find out the indexPath for an object, I'm having to keep a whole
separate NSMutableArray just of index paths, and iterate through
that array every time I want to add something to the tree -- it's
ridiculous.
That's because you're using it wrong. Sorry.
Generally, if you find something in Cocoa is "presenting [you] with
all kinds of obstacles" chances are that you're trying to go against
the grain of the framework rather than with it.
NSTreeController -- by its very name -- is not intended to be used as
the internal representation of a tree data structure. It's intended
to be used as an intermediary between your own tree data structure
(model objects) and view objects that can present it nicely to the
user. It's in the controller part of the Model-View-Controller
architecture:
Model <----> Controller <----> View
Model objects interact with each other, and their interactions with
view objects (which is what the user interacts with) are mediated by
controller objects. You're trying to use a controller object *as* a
model object, hence the ensuing headaches.
I guess I could use Core Data, but it seems like a lot just for
something that would really only have two attributes -- and strings,
at that. Does anything know of a better way to do this; a third-
party library; anything? I mean, the methods just aren't there...
You don't need to use Core Data just for this. It might be a good
exercise once you understand how things fit together without Core
Data; it'll show you what kind and amount of code you'll save, and
what features you'll gain, but I would strongly recommend walking
before you run.
Just create your own class that meets your needs in representing your
data, make sure you implement it to properly support Key-Value Coding
and Key-Value Observing -- it's important to understand here just
what's required for correctness when dealing with arrays or sets --
and you should be able to use it from your code to represent the data
in question. Furthermore, you should be able to bind interface
elements (like an NSBrowser or NSOutlineView) to it via an
NSTreeController fairly easily, as long as your KVC and KVO support
are implemented correctly.
-- Chris
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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