I have a 90 row table, in memory (BeanItemContainer). The page size is set to 20, and the caching ratio to 0.5. The table has about 15 columns. The users are used to editing a small spreadsheet, hence this choice.
When I set the table to “editable”, Firefox goes absolutely nuts, and it is impossible to scroll down (I even get the warnings about excessive time spent in script). Chrome and IE8 work fine.
I noticed that VTextField has logic to defer rendering, claiming a 10-fold improvement. This appears not to be the case. I also noticed that under Reindeer, the row size changes when switching to editable (most visible if comboboxes are present). I removed the comboboxes, and I currently have only plain TextFields in the table.
*** it can take up to a minute to scroll down *** All the CPU is in the browser as far as I can tell.
I am about to switch my application design to master-detail with a split panel, which is really a shame.
Another thought for editable tables would be to switch only the selected row to “editable”. I have started on that path, but it is a bitharder than I thought – I have not yet figured out how to reliably reset the row I have just left to “non-editable” as more is involved than just changing its css.
I actually believe that this would be a nice standard feature, especially if the rows represent relationships, in which case drop-downs or multi-selects need to appear. It is more natural to see a row “inflate” in place than to have a pop-up or master-detail
How about using PopupView. Demo is found over
here .
The popup could only contain the field, instead of a panel as in the demo. This way it would only take as much space as the “label” behind it. The downside is that filling the rows with keyboard only gets harder, as you have to click on the labels.
I thought I was running the latest, but in fact I had tested with an older nightly, based on the order of presentation in the plugin. As it turns out, the first few nightlies were labeled 6.2- and later ones are 6.2.0, so they show up below – it would be really nice if you just renamed the jars so other people don’t get bitten.
The optimization does solve the problem well enough. Not as fast as Chrome yet, but definitely acceptable.
MASSIVE THANKS !!!
(this is also a prime example of why I like Vaadin so much – just envisioning the level of gore required to implement the two-stage rendering just for Gecko is exactly what I don’t want to deal with, and you have been infinitely more resposive than, say, Dojo, on such issues).
The new nightly build versioning system was required by lately added OSGi support. This led to current confusing situation. Still, I think that it would be a bad idea to “rewrite history”. In any case - the issue will be hidden in a month or so when the 6.2.0 is released.