P4
I know work is being done on the more complex controls for JavaFX. Before these are finished I would like to suggest a usage optimization for the table component; easy data entry.
JTable is not very well suited for data entry by application users. Suppose you have a bill with order lines beneath that are shown in a table; you want the user to be able to easily type in the order (e.g. while on the phone with a client). So "articleno", "amount", "articlenr", "amount", ... Preferably using the keypad.
This requires the table to actually jump from cell to cell and also to a new line, even adding new lines on demand, using the keys on the keypad; so using ENTER instead of TAB to get to the next cell. And naturally SHIFT-ENTER to move back. Further more there may be guided navigation; if a cell has a certain value, other editable cells are skipped or even jumped back to previous columns. And there are errors or warnings on the content of a cell; suppose a certain article is out of stock; you don't neccesarily want to block the user at the time of entry, just tell him that a certain cell has a problem, so he can fix it after the order was entered.
All in all this is will increase the usability of the table component. The easy data entry is something that is used a lot if you go mainstream business application. Business application users often don't even like the mouse that much; they want easy typing. MSAccess' tables are a good example on how this could work. For Swing I've extend JTable into a JTableForEdit and added all the behavior I just mentioned. Naturally I could write a new skin on top of the JFX table, but why not get it right in the default? ;-)
There are a lot of details that need to be looked at. For example, if you automatically add a new line to a table, then you also need a new entity behind that new line. So the table implementation will moved that responsibility to the model and have the table tell the model that the table is at the visually last row and the user requested "next cell". The model can then add a new entity, thus increasing the table's row count and allowing the table to move to the cell one row down. So the table model needs additional methods for a.o. "addNewRow", "removeRowAt", "getMessage(row,col)" (error, warning or info).
However, being visually and the last row and requesting a "next cell" comes into the realm of sorting: how does sorting deal with automatically adding a new row? Will it add new rows at the end and thus break sorting, or will it add the new row and sort it immediately, moving the keyboard focus with the new row so the user can continue typing?
The "sort immediately" will result in a very jumpy screen in the user experience, because rows will be jumping all over the table, as sorted-on cell get new data. Breaking sorting is not wise; it will make the screen data inconsistent (it claims it is sorted, but it is not). So IMHO the best approach is to visually cancel sorting but keeping the rows in the last sorted order and then start adding at the end. Another approach is to postpone sorting for a short time, for example until the user has not typed any key for 1 second, and then resort the contents (always let the focus stay where it was, so move with the sorting).
This all is not a trivial change. But then again, a table is not a trivial component.
JTable is not very well suited for data entry by application users. Suppose you have a bill with order lines beneath that are shown in a table; you want the user to be able to easily type in the order (e.g. while on the phone with a client). So "articleno", "amount", "articlenr", "amount", ... Preferably using the keypad.
This requires the table to actually jump from cell to cell and also to a new line, even adding new lines on demand, using the keys on the keypad; so using ENTER instead of TAB to get to the next cell. And naturally SHIFT-ENTER to move back. Further more there may be guided navigation; if a cell has a certain value, other editable cells are skipped or even jumped back to previous columns. And there are errors or warnings on the content of a cell; suppose a certain article is out of stock; you don't neccesarily want to block the user at the time of entry, just tell him that a certain cell has a problem, so he can fix it after the order was entered.
All in all this is will increase the usability of the table component. The easy data entry is something that is used a lot if you go mainstream business application. Business application users often don't even like the mouse that much; they want easy typing. MSAccess' tables are a good example on how this could work. For Swing I've extend JTable into a JTableForEdit and added all the behavior I just mentioned. Naturally I could write a new skin on top of the JFX table, but why not get it right in the default? ;-)
There are a lot of details that need to be looked at. For example, if you automatically add a new line to a table, then you also need a new entity behind that new line. So the table implementation will moved that responsibility to the model and have the table tell the model that the table is at the visually last row and the user requested "next cell". The model can then add a new entity, thus increasing the table's row count and allowing the table to move to the cell one row down. So the table model needs additional methods for a.o. "addNewRow", "removeRowAt", "getMessage(row,col)" (error, warning or info).
However, being visually and the last row and requesting a "next cell" comes into the realm of sorting: how does sorting deal with automatically adding a new row? Will it add new rows at the end and thus break sorting, or will it add the new row and sort it immediately, moving the keyboard focus with the new row so the user can continue typing?
The "sort immediately" will result in a very jumpy screen in the user experience, because rows will be jumping all over the table, as sorted-on cell get new data. Breaking sorting is not wise; it will make the screen data inconsistent (it claims it is sorted, but it is not). So IMHO the best approach is to visually cancel sorting but keeping the rows in the last sorted order and then start adding at the end. Another approach is to postpone sorting for a short time, for example until the user has not typed any key for 1 second, and then resort the contents (always let the focus stay where it was, so move with the sorting).
This all is not a trivial change. But then again, a table is not a trivial component.