Intelligent multi-line table cells


I have a table where the cell content is a sometimes up to a paragraph worth of text. The default Vaadin behaviour is to display the text as one very long line and make the cell as wide as necessary to accomodate this. However, this does not look good in my case. What I’d like to see is:

  • Text cells should have a initial width setable as proportion of the size of the table on the screen. If the text does not fit, Vaadin should add new lines to the cell and word-wrap. Add exactly enough rows so the text fits word-wrapped.
  • If the user manually changes the column width, reflow every text cell in affected columns to match the user set width.

Is this currently possible? If yes, how?

If not, how about:

  • Text cells should have a initial width setable as proportion of the size of the table on the screen. If text does not fit the cell gets a horizontal scrollbar to scroll the text in that cell back and forth.


I think you can do this by using following code:

table.addGeneratedColumn("longText", new ColumnGenerator() {
         public Component generateCell(Table source, Object itemId, Object columnId) {
            MyTableRow item = (MyTableRow) itemId;
            // getMyFirstColumnAsString() returns a string with HTML formatting (like line breaks e.d.)
            return new Label(item.getMyFirstColumnAsString,Label.CONTENT_XHTML);

Maybe you can try the same solution as I did to wrap the text in a column. See this

for details.

Thanks Jan,

this does indeed create new lines according to HTML commands. However I have to do the line wrapping by hand. If I set a fixed length for the table column, the text that does not fit just gets cut off.

Hi Jamie,

thanks for your reply. I finally got it to work. The only things that is necessary seems to be to create your own style and add:

.v-table-cell-wrapper {
white-space: normal;


I have used this solution but it seems that in tables with a large number of rows (mine has 7000) and with pagelength > 0 sometimes the pagelength is miscalculated.

Anyone came across this issue? I have already inserted a bug on

Variable height rows in tables are only supported for pagelength = 0 (no lazy loading). Otherwise, if I remember correctly, the first row in the buffer (not necessarily the first visible row) is used to calculate the row height that is used for scrolling and other purposes (but this is an implementation detail that may change).

There are several threads about this issue elsewhere, and the main reason for this limitation is problems with making a lazy loading table with variable row height (smoothly) scrollable.

I kind of corrected by using another css rule

.disable-wrap .v-table-cell-wrapper {
white-space: nowrap;

and putting a setStyleName(“disable-wrap”) on the table. Is not Ideal but works for now… I dont know if it is possible but maybe the Table could have an alternate behaviour where the scrollbar behaved as the google+ stream or facebook timeline, with a default height in the beginning and adapting itself every time new data is loaded.


In Google+ and Facebook, you normally load data from the beginning of the page until the selected point, but that is not feasible with very large tables. Furthermore, in large tables, you often do want to skip ahead without going through tens or hundreds of “get more data” phases when scrolling to the end.

There are some ideas that would make the scroll range inhomogeneous but would enable supporting fairly smooth scrolling and variable row heights. Unfortunately, these get very complicated when they should work smoothly and intuitively together with lazy loading, and would require bypassing most of what is left of browser standard support for scrolling. This in turn would have a major impact e.g. scrolling on touch devices etc.

The problem is the following css code that hides any overflow:

.v-table-cell-wrapper { white-space: nowrap; overflow: hidden; } you will have to override the css and apply a style with :

.donthide .v-table-cell-wrapper {
    overflow: visible;