• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: advice on filtering TreeNode objects
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: advice on filtering TreeNode objects


  • Subject: Re: advice on filtering TreeNode objects
  • From: Chris Giordano <email@hidden>
  • Date: Mon, 4 Nov 2002 12:16:12 -0500

Another approach that I could see doing -- assuming that your individual data items and the tree nodes that contain them are distinct -- would be to build a separate view of the original data using a second tree structure that represents the filtered view of things.

What you end up with here is essentially three different things:
- your data items, (which may or may not exist sepearately from ...)
- your main structural organization of the items, which could/would represent the "default" view of the data (in this case, your original tree of data items)
- your "filtered" view, which is simply another way of looking at the data (here, the second tree)

Doing this, you can have as many different views of your original data as necessary without having to restructure it. When you are done with one alternate view, you just throw away that structure -- the original is still in place and holds (and retains) the original data items.

The only catch here is that if you make add or delete any data items, these changes need to be reflected in all of the various views (trees). Since the data points are shared between the various structures, changes internal to each data item will be reflected. You'll need to account for cases where you change a data point that causes the item to be included or excluded based on some filter, and you'll also have to deal with updating the actual display of the data points if, say, your filtered view of the data appears in a separate window from the main view of the data and you want to new information to be displayed in both windows.

The tradeoffs here -- to me -- seem to be space vs. time. Creating a new structure would take up more space than having filtering be an action of the node, but it seems to me that -- depending on the circumstances of its use -- it could be more efficient time-wise to do the filtering once, rather than each time the filtered data need to be displayed. It also lets you do more than one filter at once (the main view limited to pending items, and a separate filtered view based on a search, for example).


Just a few thoughts on the subject. This has been on my own to-do list for a project that I've been working on, and this is the way that I had planned on approaching it. If people have reasons why this is really the wrong way to approach this, I'd love to hear them. Reasons why it's a good approach will be accepted as well. :)

chris


On Sunday, November 3, 2002, at 03:42 AM, Alex Rice wrote:

I am using TreeNode objects for my outlineview. The treenode implementation is from Apple's NSOutlineView examples. I need to apply a filter to the root treenode and have it filter all the children on some condition, like hiding todo items that are completed, for example. I'm sure I can code it for that particular case, but I would rather implement a general-purpose filtering scheme, so I can expand it to keyword searching or other filters later on. I just can't conceptualize how to do it. Seems like there must be a design pattern here. Any suggestions? My TreeNode subclass implements NSKeyValueCoding so maybe that will help me out?

So far all I have is this method, not yet implemented:

- (void) setFilter: (TreeNodeFilter *) newFilter;

Here is the TreeNode interface

@interface TreeNode : NSObject {
@protected
TreeNode *nodeParent;
NSMutableArray *nodeChildren;
}
- (void) setNodeParent: (TreeNode*)parent;
- (TreeNode*) nodeParent;
- (void) appendChild: (TreeNode*)child;
- (void) insertChild: (TreeNode*)child atIndex:(int)index;
- (void) insertChildren: (NSArray*)children atIndex:(int)index;
- (void) removeChild: (TreeNode*)child;
- (void) removeFromParent;
- (int) indexOfChild: (TreeNode*)child;
- (int) indexOfChildIdenticalTo: (TreeNode*)child;
- (int) numberOfChildren;
- (NSArray*) children;
- (TreeNode*) firstChild;
- (TreeNode*) lastChild;
- (TreeNode*) childAtIndex: (int)index;
- (BOOL) isDescendantOfNode: (TreeNode*)node;
- (BOOL) isDescendantOfNodeInArray: (NSArray*)nodes;

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.

References: 
 >advice on filtering TreeNode objects (From: Alex Rice <email@hidden>)

  • Prev by Date: Crashing in NSUIHeartBeat thread
  • Next by Date: Re: metallized interface
  • Previous by thread: Re: advice on filtering TreeNode objects
  • Next by thread: Plug-In strategy in Mach-O / Cocoa?
  • Index(es):
    • Date
    • Thread