Skip to content
This repository has been archived by the owner on Dec 12, 2022. It is now read-only.

Grid Drag&Drop not all selected rows will be dropped #766

Closed
berndklb opened this issue Sep 9, 2019 · 6 comments
Closed

Grid Drag&Drop not all selected rows will be dropped #766

berndklb opened this issue Sep 9, 2019 · 6 comments

Comments

@berndklb
Copy link

berndklb commented Sep 9, 2019

If I select multiple rows in a Grid to drag and drop these on another grid, only the visible rows will be dropped on the other grid. All the others are still selected and not moved. Is this a bug or is this wanted behavior? Is there any documentation about drag and drop in vaadin 14 docs? See Attachment for small example.
See this forum entry for more information and a small example:
https://vaadin.com/forum/thread/17820878

@tomivirkki
Copy link
Member

tomivirkki commented Sep 9, 2019

Hi, this is expected behaviour. If you need to add more rows/data to the D&D operation, use the setSelectionDragDetails API that allows you to modify the data transfer text payload and the number shown while dragging the rows.

In the drop event listener, use the getDataTransferText() to access the generated payload (or just use the stored draggedItems if you're working inside the same browser window). See example "Custom Drag Data" at https://vaadin.com/components/vaadin-grid/java-examples/drag-and-drop

@mvysny
Copy link
Member

mvysny commented Aug 11, 2020

This is highly confusing, both to the programmer and to the user of the application. If I select 50 rows, I wish to drag 50 rows, not just some kind of a random subset of the selection. What is the reason behind dragging just the visible items? Is it performance, or other?

Just guessing: Probably the client-side Grid doesn't have information on what items there are and which of them are selected on the server-side. Still, the server-side grid could let the client-side know about the selection size.

@MacInGithub
Copy link

I just talked to Martin from Expert Chat, who told me that it is expected behaviour to drop only the visible rows on the other grid.
This cannot be communicated to our users.
Vaadin should absolutely change the multiple selection so that really all marked rows are transferred.
This is not usable and the only chance is to switch to single selection.

@mvysny
Copy link
Member

mvysny commented Aug 11, 2020

@MacInGithub it is possible to fix the Grid by applying the custom code outlined in the example "Custom Drag Data" at https://vaadin.com/components/vaadin-grid/java-examples/drag-and-drop . That way, the D&D in multi-select mode starts working as expected.

That being said, the Grid should work like that out-of-the-box. The current behaviour is confusing.

@tomivirkki
Copy link
Member

tomivirkki commented Aug 11, 2020

@MacInGithub @mvysny During the feature development, we did consider having this the default behavior but encountered technical challenges that couldn't be resolved.

One was that if someone assigns a drag filter to the grid, there's no way to know beforehand how many of the million server-side selected items should be filtered out from the drag operation. This should affect the count indicator as well as the drag data payload of the dragstart event (needed for example if you want to drag grid items to an Excel sheet or a grid on another browser window).

Another one is about dragstart event payload as well. If you select a huge number of items on the server, we'd need to send the payload data of each of them to the client which could cause a performance issue.

Vaadin 8 also has the same default behavior, most likely for the very same reasons.

@mvysny mvysny changed the title Grid Drag&Drop not all selected columns will be dropped Grid Drag&Drop not all selected rows will be dropped Aug 17, 2020
@mvysny
Copy link
Member

mvysny commented Aug 17, 2020

@tomivirkki I'm sure that there is a smart solution to this - e.g. sending the minimum amount of data to the client-side, e.g. only first 3 rows for d'n'd preview and selection count; replacing setDragFilter() with something that provides first three rows and a count that matches the drag filter (this needs to be done anyway since setDragFilter() is only usable for in-memory data sources).

The current behaviour is highly confusing and IMHO can not stay this way. Especially not if the only reasons for keeping this behaviour are technical ones.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants