- 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
This chapter is from the book
This chapter is from the book
This chapter is from the book
Editing Trees with Custom User Objects
Let's start by deciding what the user object that will be associated with a node might be. Obviously, this depends on how you are going to use the tree, but one common way to create a tree is to define a user object that contains a custom icon and a text string that can be used for display purposes, as well as any other state information that might be of use to the application itself. Storing both of these attributes in the user object allows you to have a different icon for each object in the tree instead of using the default icon provided by the look-and-feel, or using a single substitute that is the same for all nodes (or at least for all leaf nodes), as you saw when looking at how to create a custom renderer earlier in this chapter. Here's the plan for this example.
Instead of populating the tree with nodes that use Strings as the user object, this example will invent an interface that allows an object to return an icon to be rendered to represent it, then create suitable objects that implement this interface and associate them with nodes in the tree. To correctly display these nodes, a custom renderer will be needed. This renderer will get the text and the icon from the user object instead of using built-in icons or substitute icons that don't depend on the object being displayed. To edit these nodes, an editor that offers a combo box interface will be used. To ensure that the value stored in a node after the edit has completed is an object of the correct type, it will be necessary to supply our own tree model in which the valueForPathChanged method is overridden.
Let's start by defining the interface:
// An interface that describes objects with icons
interface NodeWithIcon {
public Icon getIcon();
}
From the point of view of the tree, all that is required of the user objects is the ability to get an icon and a text description from them. It isn't necessary to include a method in the interface to get a text description, because the toString method, which is defined for every Object, can be used for this.
Core Note
For simplicity, the implementation of this example is kept in a single source file. Because there can only be one public class or interface per source file, the above interface is declared with package scope. If you were developing a real application using the technique that we are explaining here, you would extract this interface into its own source file and make it public.
Next, let's define the user objects that will be used to populate the tree for our example. This example is going to use a custom data model so that a new valueForPathChanged method that knows how to map from a String to the appropriate user object that corresponds to that String can be implemented. In other words, the data model must be aware of the meaning of the objects that it contains, so the definition of the data objects is tied to the data model by defining them in terms of an inner class of the data model itself. In fact, the data model is going to be defined in such a way that its users need only know that the items that it contains implement the NodeWithIcon interface, which allows us to use other data models in place of the one that will be shown here.
Listing 10-7 shows the implementation of the tree data model and the items that will be used as the user objects in the tree.
Listing 10–7 A customized tree model class
// This class represents the data model for this tree
class CustomTreeModel extends DefaultTreeModel {
public CustomTreeModel(TreeNode node) {
super(node);
objects.put("CSM",
new HardwareObject("CSM", "images/csmicon.gif"));
objects.put("LM",
new HardwareObject("LM", "images/lemicon.gif"));
}
public void valueForPathChanged(TreePath path,
Object newValue) {
DefaultMutableTreeNode node =
DefaultMutableTreeNode)path.getLastPathComponent();
String value = (String)newValue;
// Use the string to locate a suitable HardwareObject.
// If there isn't one, just use the string as the
// user object
HardwareObject object = getObjectForName(value);
if (object != null) {
node.setUserObject(object);
} else {
node.setUserObject(value);
}
nodeChanged(node);
}
// Get the HardwareObject for a given name, or
// null if unknown
public HardwareObject getObjectForName(String name) {
return (HardwareObject)objects.get(name);
}
// Create the set of objects that can populate
// the leaf nodes
protected static class HardwareObject
implements NodeWithIcon {
protected HardwareObject(String text,
String imageName) {
this.text = text;
this.icon = new ImageIcon(getClass().getResource(
imageName));
}
// Return text for display
public String toString() {
return text;
}
// Return the icon
public Icon getIcon() {
return icon;
}
protected String text;
protected Icon icon;
}
// Get the possible hardware types in a combo box
public JComboBox getNamesAsCombo() {
DefaultComboBoxModel model =
new DefaultComboBoxModel();
Enumeration e = objects.keys();
while (e.hasMoreElements()) {
model.addElement(e.nextElement());
}
return new JComboBox(model);
}
protected static Hashtable objects = new Hashtable();
}
Let's look first at the user object class, which is called HardwareObject. This particular example will display two items of space hardware and allow the user to place either one of them into a particular location in the tree by offering a combo box with their names when the user clicks to start editing. To the left of the name, there will be a small picture that shows what the item actually looks like. To keep this example simple, only leaf items will be customized, so there is no need to supply extra icons for expanded and collapsed nodes. The same principles would, of course, be applied if you wanted to produce a completely general solution.
To create each HardwareNode object, the name of the hardware and the location of its icon must be supplied. The implementation of the Hard-wareNode class is very simple. The constructor stores the hardware name and uses the ImageIcon class to load the corresponding icon. The toString method returns the object's name and the getIcon method returns the icon. This method is needed because HardwareNode is required to implement the NodeWithIcon interface.
Because we don't want anything outside the data model to know how to create these user objects, two of them are built in the data model's constructor and placed in a hash table, keyed by their names. To complete the encapsulation, a method (getObjectForName) is provided to get a copy of the object given its name. You'll see why this method is needed later. These objects are both read-only, so it is only necessary to create one of each. Storing one copy of each in the hashtable is, therefore, acceptable, no matter how many times it might appear in the tree (and in this example it appears either once or not at all).
Thinking ahead a bit to the implementation of the cell editor, a combo box will need to be populated with the names of the possible hardware choices. Again, it isn't desirable to have the editor know how many possible choices there are or what relationship the string name that it will store might have to the objects themselves, so we implement a method within the data model (getNamesAsCombo) that returns a suitably populated JComboBox that the editor can use. This combo box is created by obtaining an enumeration of the items in the data model's internal hash table and adding one combo item per entry in the enumeration.