Control com.vaadin.ui.Grid Programmatically

I am playing with the new Vaadin Grid, and trying to integrate it with the
FieldBinder add-on
. I have a few questions:

  • If I have understood correctly, the Save/Cancel buttons of the editor are rendered client-side. Is there a way to hide them (beside CSS)?
  • Do you plan to add support to save and cancel event listeners?
  • I want to control the save/cancel behavior providing my own buttons. Grid provides the itemEdit(), saveEditor(), cancelEditor() APIs;
    [list]
  • itemEdit(itemId)
    enables and displays
    the editor
  • cancelEditor()
    closes
    the editor
    discarding
    any unsaved change
  • saveEditor()
    saves
    changes and

    does not

    close the editor
  • so, if if I have understood correctly, in order to Save & leave the editing mode I have to invoke saveEditor()
    and then
    cancelEditor()
    in sequence
    . Is this correct?

    [/list]

Thanks!

Hi Edoardo,

Currently the save/cancel buttons are pretty hard-coded, so CSS is probably the best way for now. Or you could extend Grid.Editor and replace it in the widgetset, overriding the showOverlay method and remove the buttons from DOM. Would be pretty hacky, though. Some customization for the buttons will almost certainly be added but we’ll have to think about it a bit more.

We haven’t thought about save/cancel listeners, but you could use a custom field group (Grid.setEditorFieldGroup) with overridden commit and discard. Or, of course, override saveEditor and doCancelEditor in Grid itself.

There was actually a bug in cancelEditor in that it just hid the editor without also calling discard on the backing field group. It’s fixed now:
#16199
, thanks for asking about this :smiley:

Yes, you’d have to call both save and cancel. It’s a bit unintuitive and unfortunately inconsistent with how the UI buttons work, but we wanted to provide a way to also save without closing the editor.

Hi Johannes, thanks for your reply,

If there are no technical limitations, and since the UI behavior is
already
different from the API naming, may I suggest to go further? Here are two proposal:

  • ​just add a
    closeEditor()
    (or maybe leaveEditMode()) method. The closeEditor() API would not have any
    direct
    representation in the UI, but the Save and Cancel buttons would correspond to “saveEditor(); closeEditor()” and “cancelEditor(); closeEditor();” respectively. It would be more symmetrical.
  • My understanding is that, with Grid, you wanted to go minimal; if all that saveEditor() and cancelEditor() do is invoking commit() and discard() on the FieldGroup, is it really necessary to replicate the API (with altered names) in Grid? In this case, you may just add the
    closeEditor()
    method, and recommend API consumers to use getFieldGroup().commit() and .discard() to simulate Save and Cancel respectively. The
    internal
    save and cancel API would just invoke the methods on the fieldgroup
    and
    closeEditor().

I think this would bring both consistency and avoid surprises for API consumers.

Cancel button action is not calling discard, Is there any other way to capture Cancel action is performed?

hi Johannes,

I have followed another approach you have recommended (override saveEditor and doCancelEditor in Grid itself) and its working fine. If there were listeners provided then it would have been nice. Thanks anyways.

Hi guys,

We’ve been discussing the editor API a bit and agree it’s somewhat clumsy right now. We’ll have to see what we can do about it; thanks for the feedback!

One thing we certainly will have to add at some point is more customization points for the editor buttons. Currently even the captions are hard-coded, which will obviously not fly in any application requiring localization. My current best solution is adding the user to specify any pair of regular Vaadin Buttons/NativeButtons to be used as the editor buttons; among other things, this would permit adding click listeners to the buttons:
#16271

BTW, note that you can add CommitListeners to the backing FieldGroup. Doesn’t help if you need a cancel or discard listener, though.

Apparently using
editItem()
and
cancelItem()
causes Grid to misbehave. Minimal example:

https://github.com/evacchi/vaadin-grid-bug/blob/master/src/main/java/com/example/demos/MyUI.java

Steps to reproduce:


  • Select
    the row inside the grid
  • Click the
    edit
    button: the editor is displayed (
    editItem()
    )
  • Click the
    save
    button: the row is saved (
    saveItem()
    ), and the editor closed (
    cancelItem()
    )
  • Click again the
    edit
    button


Result:
the editor line is now blank


Edit:
on the client-side (JavaScript) console, the following exception is throw when the custom
save
button is clicked for the
first time
:

Mon Feb 23 15:50:28 GMT+100 2015 com.vaadin.client.VConsole
SEVERE: Exception caught: Cannot disable: editor is in edit modecom.google.gwt.event.shared.UmbrellaException: Exception caught: Cannot disable: editor is in edit mode
    at Unknown.Cg(com.vaadin.DefaultWidgetSet-0.js)
    ... (snipped)

after a bit of debugging I realized that the problem seems to arise from the fact that clicking the built-in
Save
button causes a cleanup routine to be executed:
getEditorRpc().confirmSave().
However, this isn’t exposed in the public API

Hello

I’m currently facing the same issue with version 7.4.5
Is there any workarond?

Also, I was surprised that executing the following code raised an IllegalStateException :

grid.editItem(itemId);
grid.editItem(itemId);

FYI : Based on your example I have issued a ticket.

https://dev.vaadin.com/ticket/17842

The issue with components in editing mode has been solved in 7.5.1, but now I have a similar issue with cancelEdit().
To simplify, if you do the steps given by Edoardo Vacchi and finally tray to save again but ussing the “Save” button provided by grid, save does not work.

Hi,
Is there any enhancement concerning listener’s for the Save embedded grid button ?
my release :
Client engine version7.6.1
Server engine version7.6.1
Theme version7.6.1
Thanks…