Removed the following public cell selection methods from DataTable.java:
removeSelectedCell(String);
removeSelectedCells(String);
addSelectedCell(String);
addSelectedCells(String);
getSelectedCells();
clearCellSelection();
In the previous implementation of cell selection, cells were passed to application bean logic as CellSelections objects. These objects contained a reference to the row object as well as 'extracted' field names from the value expression (selectBy) required on any column in a table using cell selection.
This implementation was not very robust since the parsing of column value expressions for row object field names is misguided; a column value expression may access values that are not row object fields or have a complex relationship to the row object that cannot be parsed. It also precludes the selection of cells where there is no value expression. In these cases the information provided by the CellSelections object would be useless.
This parsing of field names was desired so we could supply column values to the app dev seamlessly. This now appears misguided and unnecessary. It's easy enough for the app dev to know when writing selections processing, given a Column component and row model object, if the children of that column are relevant to the processing logic and from there, setup row context and accurately resolve any value expressions the processing may be interested in. An example of this has been added to the Selection example in Showcase.
By moving value expression resolution to the app layer we break our dependency on the 'selectBy' field required for selection and makes this cell selection feature work for essentially any scenario. This new implementation eliminates alot of overhead that was required to synchronize the externally accessible CellSelection objects with an internal mapping of selections which had its own flaws. This feature is now 1/10th as long and avoids many risky behaviors the original implementation waded through.
Cell selection is now accessible from the RowStateMap like other row-specific (row selection) and cell-specific (cell editor) table feature state.
RowStateMap.getRowsWithSelectedCells -> List<Object>
RowState.addSelectedColumn(Column)
RowState.removeSelectedColumn(Column)
RowState.setSelectedColumnIds(List<String>)
RowState.getSelectedColumnIds() -> List<String>
Revision #36622
Committed by nils.lundquist
Moments ago
ICE-9411 / ICE-9384 - Simplified API for cell selection and unified with other row/cell features in RowState. Reworked selection and expansion so state changes take place in updateModel. Simplified and renamed showcase selection example.
Bug
Major
Nils Lundquist
added a comment - Revision #36659
Committed by nils.lundquist
Moments ago
ICE-9411 - Completed javadoc.
Removed the following public cell selection methods from DataTable.java:
removeSelectedCell(String);
removeSelectedCells(String);
addSelectedCell(String);
addSelectedCells(String);
getSelectedCells();
clearCellSelection();
In the previous implementation of cell selection, cells were passed to application bean logic as CellSelections objects. These objects contained a reference to the row object as well as 'extracted' field names from the value expression (selectBy) required on any column in a table using cell selection.
This implementation was not very robust since the parsing of column value expressions for row object field names is misguided; a column value expression may access values that are not row object fields or have a complex relationship to the row object that cannot be parsed. It also precludes the selection of cells where there is no value expression. In these cases the information provided by the CellSelections object would be useless.
This parsing of field names was desired so we could supply column values to the app dev seamlessly. This now appears misguided and unnecessary. It's easy enough for the app dev to know when writing selections processing, given a Column component and row model object, if the children of that column are relevant to the processing logic and from there, setup row context and accurately resolve any value expressions the processing may be interested in. An example of this has been added to the Selection example in Showcase.
By moving value expression resolution to the app layer we break our dependency on the 'selectBy' field required for selection and makes this cell selection feature work for essentially any scenario. This new implementation eliminates alot of overhead that was required to synchronize the externally accessible CellSelection objects with an internal mapping of selections which had its own flaws. This feature is now 1/10th as long and avoids many risky behaviors the original implementation waded through.
Cell selection is now accessible from the RowStateMap like other row-specific (row selection) and cell-specific (cell editor) table feature state.
RowStateMap.getRowsWithSelectedCells -> List<Object>
RowState.addSelectedColumn(Column)
RowState.removeSelectedColumn(Column)
RowState.setSelectedColumnIds(List<String>)
RowState.getSelectedColumnIds() -> List<String>
Revision #36622
Committed by nils.lundquist
Moments ago
ICE-9411/ICE-9384- Simplified API for cell selection and unified with other row/cell features in RowState. Reworked selection and expansion so state changes take place in updateModel. Simplified and renamed showcase selection example.