for an enterprise application I’m looking at replacing Table with Grid. We need a view in which a user can quicklly move through rows and columns to edit data, using only the keyboard.
Our current table implementation is very slow, most likely because of the large amount of complex (composite) fields in the Table. One possible solution would be to show only fields on selected rows and plain text on others, but that does not seem possible Using read only fields for non-selected rows might be possible, but I doubt that it will significantly improve speed.
I’ve tried the Grid component and it is exactly what we want, except that editing is painfully slow. After selecting a row, hitting Enter is sufficient to edit the row, but you need to press Tab a couple of times before hitting Enter again triggers a save. What’s more, after saving there is no longer a row/cell selected so it is not possible to move to the next row to edit.
Since I’m new to the Grid component, does anyone know possible solutions to achieve what we want?
( Come to think of it, perhaps the solution would be even better if only the current cell had an editor, and not the current row? )
The demo also supports column resize now, which have been another reason for not switching to Grid.
So, we think this will solve our issues with Grid, but honestly I don’t understand the usage model that Vaadin targeted with the original editing model. Does anyone like it?
I think perhaps the reasoning is that one row in a Grid is similar to a Form, and for Form we can have buffered editing where no changes are submitted until the user clicks “Ok” and all fields pass validation.
We don’t like this for Forms either, but there we have always been able to do setBuffered(false)
Btw: Until Grid is ready for prime-time we will continue to use a Table class where we have overridden createField to only return Fields for the current row.
This makes an editable Table much quicker, and actually usable in IE8/9, but it is really hacky and you get lots of new and interesting bugs that you have to work around or live with.
It has been open for a while. As you can see in the ticket I’ve implemented the “Enter to save” feature in Grid myself, so we are currently using some modified Vaadin jars to compile a custom widgetset.
I like your solution as well. It fast and likely touch-friendly! Thanks for posting it. I wonder, did you add a setting to move to the next row or stay on the edited row?
Also, we have some complex composite fields, including some that grow bigger with multiple values being added by the user. Would the Editor layout be able to stretch vertically with contained fields?
I am recommending to study possibilities of the un-buffered editor (i.e. setBuffered(false)) too. It is especially handy when you want to treat the whole Grid as editable canvas. Un-buffered editor also provides you the basic validation.
In case you need to have only few columns editable, and quickly jump over non-editable ones e.g. with tab-key, it is also possible to set editable renderer to those columns. I have made couple of examples (TextField and date picker) which you can find here.
I’m running into a problem with the unbuffered mode in Grid. After an item is edited, I want to automatically persist the changes to a database. When the editor is buffered, I can add a commit handler to do this, but not in unbuffered mode. So how can I detect that the user has finished editing an item (i.e. the row is no longer in edit mode)?
In unbuffered grid how to trap when user is done with editing an item. Whats the equivalent of preCommit/postCommit for un-buffered grid. Is it possible?
With the unbuffered grid, all changes are sent directly to the Container as the user tabs from field to field.
For our use this is a good thing, because it means we can listen to these changes and perform actions, like setting default values on later fields.
With the unbuffered grid we can’t, as you say, know when the user is “done”.
Instead, we have a “save” or “done” button outside.
As a rule nothing is sent to the database until that button is clicked.
We do have a few places where we listen to valueChanged on certain properties and send to the database immediately.
The demo application contains exactly the use case I am currently trying to implement (edit lines, batch save, add new rows). Is the code of the demo application available (on git)?
Hi, There is one add-on (GridFastNavigation) that adds some missing features what comes to Grid’s un-buffered mode editor, the keyboard navigation and additional events to hook on edits and movements. https://vaadin.com/directory#!addon/gridfastnavigation-add-on
Is sample code available as to how we could use it in Vaadin 7. Although the navigation to the next and previous rows with the tab key and enter to save row/column data works, I do not understood how to perform a delete. The delete key does not remove the row from the grid.