This content has been marked as final. Show 2 replies
TableViews are not really supposed to be implementations of spreadsheets; they're perhaps more akin to HTML tables, but with far more sophisticated UI capabilities.
You don't need an explicit "Add" button, even with the usual external "add new row" controls you see in the examples. You can register an event handler with one or more text fields, so that a new row is added to the table when the user presses enter. If you also do some intelligent focus requests and clear out the text fields when new rows are added, you can make a pretty slick UI where the user can just repeat a type-tab-type-tab-type-enter cycle to add rows. (This doesn't preclude having an "Add" button to support using the mouse as well.)
To more closely mimic Excel (or perhaps Access tables), you need to manipulate the item list in sophisticated ways. For example, you could wrap the "real" list in a list which adds a blank object at the end. This would mimic the Access table style, where you see the data in the table and then an extra row at the bottom for editing and adding new records. This might be pretty tricky to get just right; you will need to add new data to the "real" list when the user starts editing, then make sure the editing state is correctly preserved.
For a real Excel-like feel, you could simply have an item list with a very large number of entries, most of which would be default values (objects with all properties set to "" or null). Then the user could scroll, click, and edit as they pleased. You'd have no control over them leaving a large number of blank rows and then adding an entry way further down (but Excel allows this too...). I don't know how this would impact performance, but the TableView should be able to handle it. Scrolling might not be very intuitive.
I have managed to implement a 'workaround' based on a single empty row that is added to the table but this is a bit convoluted/error prone. Moreover the user has to click on this exact row (not the one after it or any other one) so this a bit contra-intuitive (and filling up the view with empty rows does not seem like a good way forward).
I was hoping that the design of the TableView control would have taken this kind of use case into the account. I guess I will have to implement a new control or to extend the TableView to get the required behavior. But having seen the control <--> skin responsibilities (TableView) it seems like the skin keeps a tight (private) control of all the info that is needed to assess if the user clicked outside the last populated row.