The TreeTableView control is designed to visualize an unlimited number of rows of data, broken out into columns. The TreeTableView control is conceptually very similar to the TreeView and TableView controls, and as you read on you'll come to see the APIs are largely the same. However, to give a high-level overview, you'll note that the TreeTableView uses the same TreeItem API as TreeView, and that you therefore are required to simply set the root node in the TreeTableView. Similarly, the TreeTableView control makes use of the same TableColumn-based approach that the TableView control uses, except instead of using the TableView-specific TableColumn class, you should instead use the TreeTableView-specific TreeTableColumn class instead. For an example on how to create a TreeTableView instance, refer to the 'Creating a TreeTableView' control section below.

As with the TableView control, the TreeTableView control has a number of features, including:

• Powerful TreeTableColumn API:
  • Support for cell factories to easily customize cell contents in both rendering and editing states.
  • Specification of minWidth/ prefWidth/ maxWidth, and also fixed width columns.
  • Width resizing by the user at runtime.
  • Column reordering by the user at runtime.
  • Built-in support for column nesting
• Different resizing policies to dictate what happens when the user resizes columns.
• Support for multiple column sorting by clicking the column header (hold down Shift keyboard key whilst clicking on a header to sort by multiple columns).

Creating a TreeTableView

Creating a TreeTableView is a multi-step process, and also depends on the underlying data model needing to be represented. For this example we'll use the TreeTableView to visualise a file system, and will therefore make use of an imaginary (and vastly simplified) File class as defined below:

 public class File {
    private StringProperty name;
    public void setName(String value) { nameProperty().set(value); }
    public String getName() { return nameProperty().get(); }
    public StringProperty nameProperty() {
        if (name == null) name = new SimpleStringProperty(this, "name");
        return name;
    }

    private LongProperty lastModified;
    public void setLastModified(long value) { lastModifiedProperty().set(value); }
    public long getLastModified() { return lastModifiedProperty().get(); }
    public LongProperty lastModifiedProperty() {
        if (lastModified == null) lastModified = new SimpleLongProperty(this, "lastModified");
        return lastModified;
    }

    public File(String name, long size) {
        setName(name);
        setSize(size);
    }
}

The data we will use for this example is a single root with 3 files:

 File rootFile = new File("Images", 900);
List<File> files = List.of(
    new File("Cat.png", 300),
    new File("Dog.png", 500),
    new File("Bird.png", 100));

Firstly, we need to create a data model. As mentioned, for this example, we'll be representing a file system using File instances. To do this, we need to define the root node of the tree table and its hierarchy:

 TreeItem<File> root = new TreeItem<>(rootFile);
files.forEach(file -> root.getChildren().add(new TreeItem<>(file)));

Then we create a TreeTableView instance:

 TreeTableView<File> treeTable = new TreeTableView<>(root);

With the root set as such, the TreeTableView will automatically update whenever the children of the root change.

At this point we have a TreeTableView hooked up to observe the root TreeItem instance. The missing ingredient now is the means of splitting out the data contained within the model and representing it in one or more TreeTableColumn instances. To create a two-column TreeTableView to show the file name and size properties, we write:

 TreeTableColumn<File, String> fileNameCol = new TreeTableColumn<>("Filename");
TreeTableColumn<File, Long> sizeCol = new TreeTableColumn<>("Size");

treeTable.getColumns().setAll(fileNameCol, sizeCol);

With the code shown above we have nearly fully defined the minimum properties required to create a TreeTableView instance. The only thing missing is the cell value factories for the two columns - it is these that are responsible for determining the value of a cell in a given row. Commonly these can be specified using the javafx.scene.control.cell.TreeItemPropertyValueFactory class, but failing that you can also create an anonymous inner class and do whatever is necessary. For example, using javafx.scene.control.cell.TreeItemPropertyValueFactory you would do the following:

 fileNameCol.setCellValueFactory(new TreeItemPropertyValueFactory(rootFile.nameProperty().getName()));
sizeCol.setCellValueFactory(new TreeItemPropertyValueFactory(rootFile.sizeProperty().getName()));

Running this code will result in a TreeTableView as shown above with two columns for name and size. Any other properties the File class might have will not be shown, as no TreeTableColumns are defined for them.

TreeTableView support for classes that don't contain properties

The code shown above is the shortest possible code for creating a TreeTableView when the domain objects are designed with JavaFX properties in mind (additionally, javafx.scene.control.cell.TreeItemPropertyValueFactory supports normal JavaBean properties too, although there is a caveat to this, so refer to the class documentation for more information). When this is not the case, it is necessary to provide a custom cell value factory. More information about cell value factories can be found in the TreeTableColumn API documentation, but briefly, here is how a TreeTableColumns could be specified:

 firstNameCol.setCellValueFactory(new Callback<CellDataFeatures<Person, String>, ObservableValue<String>>() {
    public ObservableValue<String> call(CellDataFeatures<Person, String> p) {
        // p.getValue() returns the TreeItem<Person> instance for a particular TreeTableView row,
        // p.getValue().getValue() returns the Person instance inside the TreeItem<Person>
        return p.getValue().getValue().firstNameProperty();
    }
});

// or with a lambda expression:
firstNameCol.setCellValueFactory(p -> p.getValue().getValue().firstNameProperty());

TreeTableView Selection / Focus APIs

To track selection and focus, it is necessary to become familiar with the SelectionModel and FocusModel classes. A TreeTableView has at most one instance of each of these classes, available from selectionModel and focusModel properties, respectively. Whilst it is possible to use this API to set a new selection model, in most circumstances this is not necessary - the default selection and focus models should work in most circumstances.

The default SelectionModel used when instantiating a TreeTableView is an implementation of the MultipleSelectionModel abstract class. However, as noted in the API documentation for the selectionMode property, the default value is SelectionMode#SINGLE. To enable multiple selection in a default TreeTableView instance, it is therefore necessary to do the following:

 treeTableView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE);

Customizing TreeTableView Visuals

The visuals of the TreeTableView can be entirely customized by replacing the default row factory. A row factory is used to generate TreeTableRow instances, which are used to represent an entire row in the TreeTableView.

In many cases, this is not what is desired however, as it is more commonly the case that cells be customized on a per-column basis, not a per-row basis. It is therefore important to note that a TreeTableRow is not a TreeTableCell. A TreeTableRow is simply a container for zero or more TreeTableCell, and in most circumstances it is more likely that you'll want to create custom TreeTableCells, rather than TreeTableRows. The primary use case for creating custom TreeTableRow instances would most probably be to introduce some form of column spanning support.

You can create custom TreeTableCell instances per column by assigning the appropriate function to the TreeTableColumns cell factory property.

See the Cell class documentation for a more complete description of how to write custom Cells.

Warning: Nodes should not be inserted directly into the TreeTableView cells

TreeTableView allows for it's cells to contain elements of any type, including Node instances. Putting nodes into the TreeTableView cells is strongly discouraged, as it can lead to unexpected results.

Important points to note:

• Avoid inserting Node instances directly into the TreeTableView cells or its data model.
• The recommended approach is to put the relevant information into the items list, and provide a custom cell factory to create the nodes for a given cell and update them on demand using the data stored in the item for that cell.
• Avoid creating new Nodes in the updateItem method of a custom cell factory.

The following minimal example shows how to create a custom cell factory for TreeTableView containing Nodes:

 class ColorModel {
   private SimpleObjectProperty<Color> color;
   private StringProperty name;

   public ColorModel (String name, Color col) {
     this.color = new SimpleObjectProperty<Color>(col);
     this.name = new SimpleStringProperty(name);
   }

   public Color getColor() { return color.getValue(); }
   public void setColor(Color c) { color.setValue(c); }
   public SimpleObjectProperty<Color> colorProperty() { return color; }

   public String getName() { return name.getValue(); }
   public void setName(String s) { name.setValue(s); }
   public StringProperty nameProperty() { return name; }
 }

 ColorModel rootModel = new ColorModel("Color", Color.WHITE);
 TreeItem<ColorModel> treeRoot = new TreeItem<ColorModel>(rootModel);
 treeRoot.setExpanded(true);
 treeRoot.getChildren().addAll(
     new TreeItem<ColorModel>(new ColorModel("Red", Color.RED)),
     new TreeItem<ColorModel>(new ColorModel("Green", Color.GREEN)),
     new TreeItem<ColorModel>(new ColorModel("Blue", Color.BLUE)));

 TreeTableView<ColorModel> treeTable = new TreeTableView<ColorModel>(treeRoot);

 TreeTableColumn<ColorModel, String> nameCol = new TreeTableColumn<>("Color Name");
 TreeTableColumn<ColorModel, Color> colorCol = new TreeTableColumn<>("Color");

 treeTable.getColumns().setAll(nameCol, colorCol);

 colorCol.setCellValueFactory(p -> p.getValue().getValue().colorProperty());
 nameCol.setCellValueFactory(p -> p.getValue().getValue().nameProperty());

 colorCol.setCellFactory(p -> {
     return new TreeTableCell<ColorModel, Color> () {
         private final Rectangle rectangle;
         {
             setContentDisplay(ContentDisplay.GRAPHIC_ONLY);
             rectangle = new Rectangle(10, 10);
         }

         @Override
         protected void updateItem(Color item, boolean empty) {
             super.updateItem(item, empty);

             if (item == null || empty) {
                 setGraphic(null);
             } else {
                 rectangle.setFill(item);
                 setGraphic(rectangle);
             }
         }
     };
 });

This example has an anonymous custom TreeTableCell class in the custom cell factory. Note that the Rectangle (Node) object needs to be created in the instance initialization block or the constructor of the custom TreeTableCell class and updated/used in its updateItem method.

Editing

This control supports inline editing of values, and this section attempts to give an overview of the available APIs and how you should use them.

Firstly, cell editing most commonly requires a different user interface than when a cell is not being edited. This is the responsibility of the Cell implementation being used. For TreeTableView, it is highly recommended that editing be per-TreeTableColumn, rather than per row, as more often than not you want users to edit each column value differently, and this approach allows for editors specific to each column. It is your choice whether the cell is permanently in an editing state (e.g. this is common for CheckBox cells), or to switch to a different UI when editing begins (e.g. when a double-click is received on a cell).

To know when editing has been requested on a cell, simply override the javafx.scene.control.Cell#startEdit() method, and update the cell text and graphic properties as appropriate (e.g. set the text to null and set the graphic to be a TextField). Additionally, you should also override Cell#cancelEdit() to reset the UI back to its original visual state when the editing concludes. In both cases it is important that you also ensure that you call the super method to have the cell perform all duties it must do to enter or exit its editing mode.

Once your cell is in an editing state, the next thing you are most probably interested in is how to commit or cancel the editing that is taking place. This is your responsibility as the cell factory provider. Your cell implementation will know when the editing is over, based on the user input (e.g. when the user presses the Enter or ESC keys on their keyboard). When this happens, it is your responsibility to call Cell#commitEdit(Object) or Cell#cancelEdit(), as appropriate.

When you call Cell#commitEdit(Object) an event is fired to the TreeTableView, which you can observe by adding an EventHandler via TreeTableColumn#setOnEditCommit(javafx.event.EventHandler). Similarly, you can also observe edit events for edit start and edit cancel.

By default the TreeTableColumn edit commit handler is non-null, with a default handler that attempts to overwrite the property value for the item in the currently-being-edited row. It is able to do this as the Cell#commitEdit(Object) method is passed in the new value, and this is passed along to the edit commit handler via the CellEditEvent that is fired. It is simply a matter of calling javafx.scene.control.TreeTableColumn.CellEditEvent#getNewValue() to retrieve this value.

It is very important to note that if you call TreeTableColumn#setOnEditCommit(javafx.event.EventHandler) with your own EventHandler, then you will be removing the default handler. Unless you then handle the writeback to the property (or the relevant data source), nothing will happen. You can work around this by using the TreeTableColumn#addEventHandler(javafx.event.EventType, javafx.event.EventHandler) method to add a TreeTableColumn#EDIT_COMMIT_EVENT EventType with your desired EventHandler as the second argument. Using this method, you will not replace the default implementation, but you will be notified when an edit commit has occurred.

Hopefully this summary answers some of the commonly asked questions. Fortunately, JavaFX ships with a number of pre-built cell factories that handle all the editing requirements on your behalf. You can find these pre-built cell factories in the javafx.scene.control.cell package.