commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kief Morris <>
Subject Re: [Collections] TreeNode, TreeIterator, IdentityHashSet proposed collections
Date Mon, 01 Apr 2002 06:54:55 GMT
> > Which suggests the right approach to take is to
> leave TreeNode as it is,
> and consider whether to make an implementation of
> Tree that uses TreeNode
> for its guts.
> This was kind of where I was heading. What if the
> keys in your
> implementation became TreeNodes?

I'm not sure I see the point? I think TreeNode ought
to simply replace TreeEntry. A basic implementation of
Tree would just provide a Collection-based interface
(in the general sense of the word, not the Java sense)
for accessing TreeNodes, no use of keys. 

For my application which uses keys, I would subclass
TreeNode to include a key field. The key-based tree
should be an extension of the non-key-based tree (as
James Strachan suggested). But there's no reason to
use keys in the base implementation.

Let me explain why am I using a keyed Map. My
application stores a tree structure in a database, a
hierarchy of topics under which content items can be
posted (think Yahoo directory). When I build my tree,
I use the primary key field from the table as the key,
and I link children and parents based on a references
(i.e. a self-referencing parent_id field in the
table). HTML links for navigating the directory use
this ID to identify the node in the directory, so
being able to do a Tree.get(id) to get the node is

I'll start drafting up some code for this.


Do You Yahoo!?
Yahoo! Greetings - send holiday greetings for Easter, Passover

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message