A number of changes to TableView and related classes broken down into a few categories:
Change 1:
* remove TableColumn.observableProperties
* remove TableColumn.property
* remove TableColumn.dataRetriever
* add TableColumn.cellValueFactory concept:
* Rather than have a dataRetriever return the actual value to be displayed, have the cellValueFactory return an ObservableValue representing the value. This way any changes to the underlying value will be immediately displayed.
* Provide a pre-built PropertyValueFactory to javafx.scene.control.cell to make it trivial to populate. Consider providing additional CellValueFactories in future releases.
* For example: firstNameColumn.setCellValueFactory(new PropertyValueFactory("firstName"));
* When the PropertyValueFactory convenience class is not suitable, then the fully implemented CellValueFactory would look like the following:
setCellValueFactory(new Callback<CellDataFeatures<Customer>, ObservableValue<String>>() {
@Override public ObservableValue<String> call(CellDataFeatures<Customer> f) {
return f.getValue().firstNameProperty();
}
});
* If the value to return is not an ObservableValue, then it could be wrapped by another convenience class (e.g. a JavaBeanAdapter(f.getValue(), "firstName");)
* TableColumn will provide a default edit commit handler that checks whether the ObservableValue is also a WritableValue. If so, we write to it. Otherwise the developer must specify onEditCommit.
Change 2:
* add TableView reference to TableColumn,
* add generic types to TableColumn (e.g. TableColumn<T, S> where T is the type of the TableView, and S is the type of the TableColumn) and TableColumn.CellDataFeatures
* add generic types to other Table* classes to include the TableView type (TablePosition, TableView.EditEvent, etc).
Change 3:
* Remove all editing API from TableView (which is only relevant for row editing which is not major for Presidio). Rename and revise TableView.EditEvent to TableView.CellEditEvent (and optionally relocate to the TableColumn class).Make this class more specific about cell edit events.
* This means that cell edit events will only fire on TableColumn, and row edit events will fire eventually only on TableView. Currently cell edit events fire on TableColumn and TableView.
Change 4 (small API changes):
* add a row integer property to CellDataFeatures
* Rename TableView.setColumnControlEnabled to TableView.setTableMenuButtonVisible (in preparation for adding TableView.setTableMenuButtonItems(...) in a future release)
* Replace TableColumn.sortAscending boolean with a SortType enumeration of initially (SortType.ASCENDING, SortType.DESCENDING), but eventually also may grow to include SortType.UNSORTED
* Make TableColumn.getCellData methods final
Justification: API cleanliness, maximum power and flexibility, and able to be used more cleanly from FXML.
Change 1:
* remove TableColumn.observableProperties
* remove TableColumn.property
* remove TableColumn.dataRetriever
* add TableColumn.cellValueFactory concept:
* Rather than have a dataRetriever return the actual value to be displayed, have the cellValueFactory return an ObservableValue representing the value. This way any changes to the underlying value will be immediately displayed.
* Provide a pre-built PropertyValueFactory to javafx.scene.control.cell to make it trivial to populate. Consider providing additional CellValueFactories in future releases.
* For example: firstNameColumn.setCellValueFactory(new PropertyValueFactory("firstName"));
* When the PropertyValueFactory convenience class is not suitable, then the fully implemented CellValueFactory would look like the following:
setCellValueFactory(new Callback<CellDataFeatures<Customer>, ObservableValue<String>>() {
@Override public ObservableValue<String> call(CellDataFeatures<Customer> f) {
return f.getValue().firstNameProperty();
}
});
* If the value to return is not an ObservableValue, then it could be wrapped by another convenience class (e.g. a JavaBeanAdapter(f.getValue(), "firstName");)
* TableColumn will provide a default edit commit handler that checks whether the ObservableValue is also a WritableValue. If so, we write to it. Otherwise the developer must specify onEditCommit.
Change 2:
* add TableView reference to TableColumn,
* add generic types to TableColumn (e.g. TableColumn<T, S> where T is the type of the TableView, and S is the type of the TableColumn) and TableColumn.CellDataFeatures
* add generic types to other Table* classes to include the TableView type (TablePosition, TableView.EditEvent, etc).
Change 3:
* Remove all editing API from TableView (which is only relevant for row editing which is not major for Presidio). Rename and revise TableView.EditEvent to TableView.CellEditEvent (and optionally relocate to the TableColumn class).Make this class more specific about cell edit events.
* This means that cell edit events will only fire on TableColumn, and row edit events will fire eventually only on TableView. Currently cell edit events fire on TableColumn and TableView.
Change 4 (small API changes):
* add a row integer property to CellDataFeatures
* Rename TableView.setColumnControlEnabled to TableView.setTableMenuButtonVisible (in preparation for adding TableView.setTableMenuButtonItems(...) in a future release)
* Replace TableColumn.sortAscending boolean with a SortType enumeration of initially (SortType.ASCENDING, SortType.DESCENDING), but eventually also may grow to include SortType.UNSORTED
* Make TableColumn.getCellData methods final
Justification: API cleanliness, maximum power and flexibility, and able to be used more cleanly from FXML.
- blocks
-
JDK-8113798 MemoryLeak in TableColumn.observableProperties list
- Closed