Vaadin 7.4.0.rc1 - Grid not usable

Vaadin 6 / 7 / 8
1

I have been eagerly waiting for the new Grid component since it was announced, and had really looked forwards to migrate away from the crappy Table component.
Unfortunately it doesn’t seem that it can replace Table just yet.


Dealbreakers:

  1. The editor row is just not usable

double-click on row 1
click in field
write values
click save
double-click on row 2
click in field
write values
click save
​…

Just, no.
This should have been:

click in field in row 1
write values
click in field in row 2
write values

or even better:

click in field in row 1
write values
arrow-down
write values

From this also follows that the editor shouldn’t freeze the Grid.

I hear Vaadin is working on a spreadsheet component.
You can’t possibly plan to use the current Grid for that?

  1. Not possible for the user to resize the columns.

So, when you have a column that can contain a long text, I either have to always show everything, always leaving less room for the other columns, or I have to truncate the text / set a smaller width?

I assume this will appear in 7.4.x or something, but it annoys me that basic features have been prioritized down to make room for the new and shiny. I do appreaciate the new stuff, but I would have preferred if Grid 1st was a drop-in replacement for Table.


Annoyances:

I don’t like the way row selection works;
Say you have two lists; In both you want to single-select all the time, but in one of them you occasionally want to do multi-select as well. The users will have to do single-select in a different way in these two lists…
Clicking a row in a multi-select list should select it, just as in a multi-select list.

However, I do like the checkbox, and especially the click-drag to select multiple rows. We do have users that don’t know or are uncomfortable with using shift and ctrl to select.

I think that shift-select and ctrl-select to select a range of rows in a multi-select list should always work, and the checkbox should be an option.


Amusing bugs and quirks:

When I double-clicked a row to edit it in IE9, the text I clicked on got selected, naturally. I then got the editor row on top of that, and on top of that again I got the IE “accelerator” button which gives you such helpful options as “Email with Windows Live” and “Search with bing”.

zooming with ctrl-mousewheel doesn’t work.

2

Thanks for the comments. Perhaps others will comment other points, but I completely agree with the awkwardness of keyboard editing and navigation in the first version of Grid.

There’s now the following suggestions for enhancing keyboard navigation in Grid:

  • Closing grid editor loses focus from row (
    #16384
    )
  • Allow row focus in addition to cell focus in Grid (
    #16387
    )
  • Allow keyboard row navigation in Grid editor (
    #16389
    )
  • Tab should only cycle through row fields in Grid editor (
    #16841
    )
  • Pressing Enter should save edited row in Grid (
    #16842
    )

I hope those cover all the keyboard issues you had, and perhaps some more. Feel free to comment on the usefulness of the suggestions.

3

Those issues would make it better, but I think the main problem remains.

In my opinion the editor-row is a workaround we developers add because making everyting into proper input fields is too expensive. No user has asked us to please replace a fully editable list with one where just one row is editable at a time.

From this follows that the editor row should be as transparent as possible.
If you accept that then you see that the current edditor line just isn’t the right approach.

I wonder: With this new Grid component, have you tried to render a screenful of editable fields?
I know this is terribly slow with IE9 and the old Table component, but I don’t know why it is slow.
Our old framework spit out hundreds of rows with editable fields without any apparent problems.
This worked fine even back with IE8, so I don’t know why just a screenful of editable fields is a problem now.

Some comments on the specific issues:


Allow row focus in addition to cell focus in Grid (#16387)

I like the current behaviour, but I expect that when I press return the cursor is placed in the focused cell.


Pressing Enter should save edited row in Grid (#16842)

I alluded to it above, but I think the save and cancel buttons must go…
Whether you have edited or not, arrow up/down, click in list etc should just work.

I tried to do grid.getEditorFieldGroup().setBuffered(false) but that had no effect on the buttons at least.

4

Thank you for your feedback. Our approach with Grid has so far been to produce an initial version that would let us get feedback on the new approaches we are introducing. For this reason, features that we already “know” how to do based on how Table works have been a lower priority even though that means that Grid is not yet ready to replace Table in all use cases.

We will add currently missing features in upcoming minor releases - there’s already an ongoing project that will add some of those based on feedback from the 7.4.0 beta releases. Vaadin 7.5 is scheduled for the end of Q2 and should for Grid contain at least column reordering using drag and drop and column hiding (known as column collapse in Table). Column resizing is also among the top items on our own wishlist, but we will focus on getting 7.5 out early instead of delaying it by including all possible features.

Your suggested UX for editor row is something that we were also considering even though we chose to leave it out from the initial release because we weren’t sure about some usability aspects. Our main challenge was how the user could know and control when changes were committed and how to undo undesired changes if we would allow editing another row without explicitly saving or canceling the current changes. For similar reasons, we also chose to freeze scrolling while an editor is open to avoid situations where the user accidentally scrolls to some other location and then has problems finding the open and uncommitted editor row. Do you have any insights on these potential issues?

Vaadin Spreadsheet 1.0.0 beta1 was released just last Friday and it’s based on a completely differ architecture and UI model that closely follows established spreadsheet conventions similar to how e.g. Excel works. You can try it out at
http://demo.vaadin.com/spreadsheet/
 - please notice the initially loaded example is implemented to only allow editing in certain of cells.

5

Also - maybe I am missing something here - but I can’t find how to set Visible Columns the way it works with a table.
I have a Container data source with beans containing quite a few fields, and I don’t need all to show.

6

This is achievable with in a slightly different way compared to Table. Instead of “collapsing” or “hiding” a column, you simply remove it from Grid (it will still remain in the container, and can be added back to Grid later on if needed). Please see
this tutorial
 for a simple example where a column is removed from Grid.

We are also about to implement functionality similar to column collapsing from Table so that you can let the user hide columns through the UI.

7

Yes, I knew about that.
But it’s still not very usable. In my case, I have a pojo representing a json object received from a server, with about 20 fields.
And I only need to display 3.
With a table it’s just setVisibleColums.
With the grid I need to hide everything. And then, if the server response will include more or less fields in the future, I will either get NullPointerExceptions or have columns suddenly appear.

I also tried removeAllColumns on the drid, and then adding back only what I needed, but apparently that delets the underlying data.

I think some way of just filtering the visible columns must be added.

8

I’m not sure I understand what kind of situation you’re referring to. Could you please file a ticket about this in
our bug tracker
?

Removing columns from Grid should not affect the Container, other than in the case when using the default container and adding data using Grid.addRow. Could you provide some additional details for this?

This is will most likely be introuced as part of the feature that lets the end user control which columns are visible. This is planned for Vaadin 7.5 that is scheduled for Q2.

9

I was using the compact and small styles with the Table component.
They don’t work in Grid component. Should I fill a ticket ?

grid.addStyleName(ValoTheme.TABLE_COMPACT); // “compact”
grid.addStyleName(ValoTheme.TABLE_SMALL); // “small”

10

In this forum are a lot of questions/problems about Grid waiting for answers. looking at Leif and Marko :slight_smile:

11

The styles defined in the ValoTheme enum (or any other theme enum) are component-specific; those are for the Table component. There are “small” styles for many components, such as LABEL_SMALL, BUTTON_SMALL, LINK_SMALL, etc. If some component doesn’t have such enum item, it usually means that it doesn’t support it.

Grid currently does not support any component-specific style names. I guess you could reuse those “compact” and “small” names if you implement the modifications in a custom theme.

Note that, while your issue is not a defect, it would be a good subject for an enhancement ticket. I’m sure Grid would benefit from those sizing styles just like Table does.

12

Thanks for the answer Marko,

I don’t have enough understanding of the theming/css part to modify it myself. But I though that “compact” and “small” is something that would be good to have in the Grid component. That is why I asked if I can add a ticket :slight_smile:

13

David, please add a ticket for those additional style names, those should be added at some point.

14

Hope my english works for the description.
Here is the ticket
http://dev.vaadin.com/ticket/16937#ticket

BTW, it’s my first ticket here from Asuncion, Paraguay. Next time I will try to add a patch also.
Great work with the Grid Component!

15

Absolutely this.

Glad I catched this thread, since we haven’t tested Grid yet, and quite astonished to hear that there’s no way to set visible columns like we have for Table, but that you have to hide them explicitly.

We have heavy JPA entities with 50+ fields and only show 5-8 of them in tables - the rest of them are available via forms (with multiple tabs), and several of them are for internal use only. We have even developed custom annotations to hint which fields should be shown by default for each entity… and they’re of course whitelists, i.e. they only contain the small subset of the fields that you want to show in the table, the most important columns usually. We also need to select the set of visible columns dynamically at runtime according to the current context.

It’s difficult for us to conveniently replace Table until a simple, direct way to select which properties would be visible is available. If we used the current mechanism, every single customization (and we plan to do a lot of them for our customers) that requires an extra field, maybe internal, would end up showing it in the Grid unless we remember to explicitly hide it. No way…

I also hope that column hiding, when available, might allow to select the columns available for showing/hiding in the dropdown instead of just assuming that all fields are to be listed as “potentially visible”.
To sum it up, there are 3 sets of fields:

  1. all the properties in the container
  2. columns that you may show in the table (available in the dropdown for Table)
  3. columns currently showing (i.e. not collapsed/hidden)

and generally speaking, they’re three very distinct sets, with set 2 possibly much, much smaller than set 1. And quite dynamic, too.

…guess the bottom line is that demo beans having just 4 or 5 fields aren’t really representative of the real world :wink:

16

i need code to export grid to excel . please help me

17

i need code to export grid to excel . please help me

18

You would want to do that with the container, not with the Grid itself.

I did a very simple Grid to CSV some weeks ago:

private String getCurrentListAsCsv()
    {
        StringBuffer sb = new StringBuffer();
        
        List<Column> columns = mainGrid.getColumns();
        
        boolean firstCol = true;
        
        for ( Column col : columns )
        {
            if ( !firstCol )
                sb.append(";");
            
            String propertyValue = col.getHeaderCaption();
            sb.append("\"");
            sb.append(propertyValue.replace("\"", "\\\""));
            sb.append("\"");
            
            firstCol = false;
        }

        sb.append("\n");
        
        for ( Object entry : gridContainer.getItemIds())
        {
            firstCol = true;
            for ( Column col : columns )
            {
                if ( !firstCol )
                    sb.append(";");
                
                String propertyValue = String.valueOf(gridContainer.getItem(entry).getItemProperty(col.getPropertyId()).getValue());
                sb.append("\"");
                sb.append(propertyValue.replace("\"", "\\\""));
                sb.append("\"");
                
                firstCol = false;
            }
            
            sb.append("\n");
        }
        
        return sb.toString();
    }

Hope that helps. If you want to create an XLS or XLSX file you should probably use an appropriate library for that purpose.

19

As Samuel noted above, this is a data layer topic, and as such not related to Grid or actually even Vaadin.

I would recommend an MS document manipulation library, such as Apache POI, for creating Excel files, although it probably requires some effort to use. We use Apache POI in Vaadin Spreadsheet, and it works without trouble at least for basic sheet functionality.