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: Sam Stigler <email@hidden>
- Date: Tue, 29 May 2007 02:38:07 +1000
Thanks for that much-needed correction. I just got a good start on
making my own class etc. as you suggested, and it's turning out very
well. As much as I hate to say it, it's almost as if moving to Cocoa
made me forget some core facets of programming (like "Hey! you don't
have to use Core Data or another Apple framework! you can roll your
own class!) simply because I hardly needed to use them anymore. It's
really been a great exercise to go through the process of designing
and coding the class. Time consuming? A little, but definitely
worth it. KVC and KVO, if I read the documentation correctly, were
basically no problem to implement -- my method names basically took
care of that from the start. However, I won't know until I complete
the refactoring whether I they are actually working or not.
One thing I have been having trouble with is this: The main class I
made is an "AmazonBrowseItem" class (I guess comparable to the
NSMutableDictionary that's the default for the NSTreeController), and
each AmazonBrowseItem contains a "children" array, but how do I keep
track of several root AmazonBrowseItems in the controller? Right now
I improvised by making an "AmazonBrowseTree" class that's basically
just an array of AmazonBrowseItems, but I doubt that will play well
with the controller because it has far less setters and getters than
an AmazonBrowseItem. I'm sure this is something really basic that
I'm just over-thinking, but if anybody could clear this up for me I'd
really appreciate it.
As for what you were saying about MVC, I had that in the back of my
mind, but I had been told before that it was okay to
NSArrayController directly as a model so I extended that to
NSTreeController. I assume that's wrong about NSArrayController?
Oh, and in response to your question about the Java tree classes --
just be to clear, I wasn't referring to any bindings-capable ones, of
course, but simply just ones that get the job done. I just checked
on the Java 1.5 API page (which I haven't been to for a while, and I
actually didn't find much in the way of tree classes, but did find
one ("TreeNode") that's also a GUI class but offers marginally better
programmatic features. Moderator: Sorry that this paragraph is OT.
-Sam
On May 28, 2007, at 10:29 PM, Chris Hanson wrote:
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