- The Tree Control
- Tree Appearance
- The TreeNode Interface
- The MutableTreeNode Interface
- The DefaultMutableTreeNode Class
- The TreePath Class
- What is a Leaf?
- Tree Expansion and Traversal
- Expanding and Collapsing Nodes under Program Control
- Tree Expansion Events
- Making Nodes Visible
- Controlling Node Expansion and Collapse
- Tree Model Events
- Implementation Plan for the File System Control
- File System Tree Control Implementation
- Using the File System Tree Control
- Custom Tree Rendering and Editing
- Customizing the Default Tree Cell Renderer
- ToolTips and Renderers
- Custom Cell Editors
- Controlling Which Nodes Can Be Edited
- Controlling Editability by Subclassing JTree
- Programmatic Control of Editors
- Editing Trees with Custom User Objects
- The valueForPathChanged Method
- The Tree Implementation
- The Cell Editor
- The Cell Renderer
- Summary
The MutableTreeNode Interface
The MutableTreeNode interface adds the following methods to TreeNode:
public void insert(MutableTreeNode child, int index) public void remove(int index) public void remove(MutableTreeNode node) public void removeFromParent() public void setParent(MutableTreeNode parent) public void setUserObject(Object userObject)
By contrast to TreeNode, these methods are entirely concerned with creating and changing the parent-child relationships between nodes. The insert method adds the given node as a child of the node against which it is invoked, specifying the index that should be used for the child. DefaultMu-tableTreeNode provides a more convenient way of adding children that doesn't require you to keep track of indices, as you'll see shortly. The remove methods disconnect a node from its parent given either the node reference or an index. Whichever variant of remove you use, you must invoke this method against the parent of the node that you want to remove. To remove a child node without a reference to its parent, invoke removeFromParent against the node itself.
The setParent method sets the reference from a child to its parent. You are very unlikely to want to use this method, however, because it doesn't make the parent itself aware of the child. This method is really intended for use in the implementation of the other MutableTreeNode methods, such as insert.
The last method in this interface is setUserObject, which associates an arbitrary object with the node. This is, in fact, the only way to make a node useful. The other methods of MutableTreeNode deal with the construction of the tree, but this method allows you to say what the objects in the tree represent. In the examples shown above, the strings One, Two, Three and so on were the useful content of the tree (although "useful" might not be the right word in the case of this trivial example). They are stored in the tree as the user objects of the nodes that represent them. If you use the DefaultMu-tableTreeNode class to create your nodes, you supply the user object to the constructor, and you can also use the setUserObject method to change the associated object later.
Now let's look at the DefaultMutableTreeNode class which, as has been said, implements a superset of the MutableTreeNode interface. Unless you're implementing a very lightweight tree and have special requirements, it's not worth considering implementing your own MutableTreeNode class. All of the examples in this chapter will directly use or derive from Default-MutableTreeNode.
Core Note
While this section is concerned with tree nodes as part of the JTree component, it is worth bearing in mind that the tree model can be used on its own without reference to the tree control. You could, for example, use DefaultTreeModel to implement a tree to hold information used internally by your application. If you intend to do this and memory is a concern, you might consider implementing a lightweight implementation of MutableTreeNode that suits your specific requirements.
DefaultMutableTreeNode has too many methods to list them all hererefer to the API specification if you want to see what they all are. Many of them will be covered here and in the following sections.