Re: advice on filtering TreeNode objects
Re: advice on filtering TreeNode objects
- Subject: Re: advice on filtering TreeNode objects
- From: Alex Rice <email@hidden>
- Date: Tue, 5 Nov 2002 10:57:30 -0700
On Monday, November 4, 2002, at 09:38 PM, Andreas Mayer wrote:
Depends. If you need the filtering elsewhere, this might be the right
approach. If you only need it in the outline view, you may add it to
the corresponding data source methods, like
- (int)outlineView:(NSOutlineView *)outlineView
numberOfChildrenOfItem:(id)item
and
- (id)outlineView:(NSOutlineView *)outlineView child:(int)index
ofItem:(id)item
This is true. Since the filtering isn't in reality part of the data
objects, or the Tree data structure it may as well happen in-between
the View and the Model.
Hm. If I'm not mistaken, a subclass has - per definitionem - knowledge
of anything that it's superclass knows. That's the point of
subclassing, no? As a matter of fact, I think that in this case - for
exactly the reason you stated (ToDoItems do not need any knowledge of
the tree structure), ToDoItem should _not_ be a subclass of TreeNode.
Instead TreeNode should hold references to the ToDoItems - just like
the NSDictionary and NSArray classes work.
Yep, the NSOutlineView examples from Apple did not subclass TreeNode,
rather they held references to the data objects. However, it was
confusing me at first and subclassing treenode was kind of a
simplification for myself.
My implementation of NSOutlineViewDataSource just calls methods in
the TreeNode interface to return the correct item the NSOutlineView.
You mean you implemented the data source methods in the TreeNode
class? I woudn't do that, unless you want to limit the use of the
TreeNode class to trees that are data sources for outline views.
No I implemented NSOutlineViewDataSource in my NSDocument class. But
it's just doing things like this
- (int) outlineView: (NSOutlineView *)outlineView
numberOfChildrenOfItem: (id)item
{
ToDoItem *node = (item) ? item : [[self model] rootNode];
return [node numberOfChildren];
}
Sorry, no. But I'm thinking about something like this:
- @interface TreeNode : NSObject
// the basic tree class
- @protocol FilterProtocol
// a protocol that declares filter methods - something like -
(BOOL)isFiltered:(id)object
- @interface TreeNode (Filtered) <FilterProtocol>
// a category to the tree class that implements the filter protocol
- @interface ToDoItem : NSObject
// just holds the data
- @interface ToDoItemOutlineViewDataSource : NSObject
// knows about the tree that holds the toDoItems and the nature of the
toDoItems themselves
Whether you want to implement the FilterProtocol for the TreeNode
class or the ToDoItem class depends on what data you need for
filtering. Or maybe you find it easier to put that code directly in
the ToDoItemOutlineViewDataSource class.
The advantage of this design is, that you get three building blocks
independent of each other and fully reusable: A tree class, a to do
item class and a filter protocol. Only the data source class, that
ties everything together, is specialized.
I hope that helps somewhat. If not, please excuse me - it's 5:30 AM
right now ... ;-)
Yes, helps a lot. Thanks,
Alex Rice <email@hidden>
Mindlube Software
http://mindlube.com/
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.