views:

52

answers:

3

I have a database table. I want the user to be able to modify the values in that table, through a web UI.

As such, I have my back-end retrieve the table's values, pass them to my Javascript through JSON. My Javascript builds objects representing table rows, and then uses prototype templates to generate HTML table rows, from the data.

this.varietyRowTemplate = new Template(
        "<tr class='#{stockLevel}'>" +
        "<td class='name'>#{name}</td>" +
        "<td class='source'>#{source}</td>" +
        "<td class='colour'><span class='colour'>#{colour}</span><input class='colour hiddenInput' type='text' value='#{colour}' /></td>" +
        "<td class='type'><span class='type'>#{type}</span><input class='type hiddenInput' type='text' value='#{type}' /></td>" +
        "<td class='packetSize'><span class='packetSize'>#{packetSize}</span><input class='packetSize hiddenInput' type='text' value='#{packetSize}' /></td>" +
        "#{yearCells}" +
        "<td class='total'>#{localStock}</td>" +
        "<td class='inventoryUpdate'><input class='inventoryUpdate' type='button' value='Update'/></td>" +
        "</tr>");
...
...
    //For every variety in the object array, add a row to the table
    tableString += this.varietyRowTemplate.evaluate(variety);

I then set the container's innerHTML to the table string

tableContainer.innerHTML = tableString;

With a table of 2,000 rows, 15 cells per row, ~10 input elements per row, as well as ~15 span tags, this takes me over a minute.

Is there a substantially faster way to generate and populate a large table? Should I give up trying to display all 2,000 rows at once, and break it up into pages? (Note - growing the table at say, 25 rows at a time, as they load is unacceptable, because the last elements will still take a minute to load).

+1  A: 

I once had a similar issue and solved it with an infinite scroll.

I found it was significantly quicker to grow the table incrementally by copying new row objects to the tbody (using the DOM table API) than it was to keep appending blocks of html to the end (the latter needs to parse the entire HTML each time - hence your bad experience with adding the last elements)

Hope this helps

angusC
I've found that using DOM methods for that much HTML, especially tables, is dog slow on IE.
Robusto
I don't append rows one at a time - I build the entire table, and then ask the browser to render it - although I can see how this concern would be relevant if I were to add rows on-the-fly.
Vladislav
+1  A: 

What I would do is store the data on your browser, which is trivial, then show a table of about 100 rows at a time. Sort the data by column using Array.sort() (pass it a sorting function for different data types) and remember which page you are on so that it doesn't always reset to top or bottom. I've done this easily with 5K rows of data and it's lightning fast.

One other trick I've used is having a single table row and one TD per column. Then I fill each TD with a stack of data containers, taking care to make sure they're the same height. That makes a faux table, but if you do it right the user can't tell the difference. It's orders of magnitude faster than rendering all those rows.

Robusto
Given that I want to retain the browser's find functionality, I'll have to go with this - probably with each page representing alphabetical ranges. Given that a common factor of the advice so far has been: "Don't render tables with 2000 rows", this seems to be the best solution for me.
Vladislav
+1  A: 

The template might simplify things from a coding perspective, but it's costing you a lot. First, there's the search-and-replace operation to insert the values for each object. Then there's the overhead of discarding and creating an increasingly long collection of string objects with the += operator. Finally, the innerHTML string needs to be parsed into a DOM document fragment before it can be inserted into the table.

Even though the code may be a lot more verbose, creating and appending TR nodes directly from the evaluated JSON objects using DOM methods is going to be a heck of a lot faster and if you create the table in a scrollable region, most of the rendering will be hidden from the user (and, if you wish, can be done on demand in response to the user's scrolling -- the hard part if you go that route is guesstimating the rendered height of the entire table so you can position the scroll thumb appropriately despite there being an incomplete table).

Stan Rogers
I'll keep the performance hit in mind - I may have my JSON-generated objects build their row representations themselves.
Vladislav