In Vaadin 7.6 we have made a huge effort for customisations in the Grid component. Two major customisation points are the selection models used in Grid and the event handling in Editor. Client-side customisations are possible for both of them, and can have a huge effect on the UX and the behaviour of Grid. Selection models can be modified on the server-side alone, if you want to change things, like limit the amount of rows selected in multi selection.
Customize Selection Models
The selection models in Vaadin 7.6 have been changed from using Grid’s state and communication and are now based in the data and handling their own communication. This was done along with a major redesign of the Grid data that allows anyone to create an Extension that modifies the data being sent to the client by implementing the DataGenerator interface.
The refactor of selection models allows you to extend an existing selection model and modify the limitations in it. The client-side gives you a good base to build on and a couple of common features to extend or override.
In the example below, I’ve removed the selection column from the MultiSelectionModel. First extend the server-side of the selection model to correctly map the client-side connector. In that connector I have overridden the method createSelectionModel to return my own custom client-side selection model. And in that model, I changed it to return null when creating the selection column renderer. This way no selection column is added to Grid. You can create your custom selection column renderer as well, just return that instead of the empty value.
Another thing to easily modify are the listeners the selection model adds to Grid. You can, for example, listen to a context menu event and do the selection with that. Just implement the EventHandler you need, and add it as a handler to Grid. Remember to clean up any listeners in onUnregister method, if you ever change the selection model.
Customize Editor Navigation
In the client-side of Vaadin, there is now an interface called EventHandler in the Editor class, which is used to handle events while the editor is open.
The client-side includes a default implementation in the DefaultEditorEventHandler class. In this implementation, while using the unbuffered version of Editor, it behaves like Spreadsheet in Google Drive. Enter key is used to move the editor up and down, depending on the Shift key. Tab is used to navigate vertically in the editor, and at the end of the row, the editor is moved to the next row. With buffering enabled, Tab stops at the first or last column of the Grid, depending on the direction.
This can be relatively easily altered by creating a simple Extension for Grid that sets an alternative EventHandler for the editor in the ExtensionConnectors extend method. You can either override some methods of DefaultEditorEventHandler or make a completely new one from scratch. The default implementation is split into separate methods, and can be easily overridden to handle some cases differently.
The example code for modifying this behaviour can be found on my GitHub in custom-grid-demo repository. An interesting part of the example is the client-side connector of the EditorHandlingOverrideExtension. The events handled in the example are Ctrl/Cmd + arrow keys. Some Tab events are also handled to maintain the Grid scroll position. The example also overrides the Editor opening to be done with only a single click instead of a double click.
Modifying how the editor events are handled takes some understanding of how the browser events work, but since most of the needed features are already provided, you can just find the events you want to move the editor with, and call editRow method of the DefaultEditorEventHandler providing the new row index and column index. You can implement solutions for Page Up/Page Down to move the editor some hard-coded index count or use some calculations to determine the size of the Grid page. Best case for this is of course Grid with height mode rows.