fnFormatDetails example - right tool for this job?

fnFormatDetails example - right tool for this job?

GregPGregP Posts: 500Questions: 10Answers: 0
edited May 2011 in General
On its surface, the question answers itself. I want to make a "details" view for each of my rows, almost identical in visible functionality to this:

http://datatables.net/examples/api/row_details.html

But I wanted to confirm that I'm using the right tool for the job for my particular implemenation before going crazy with code. I'm overly safe that way I guess. ;-)

Looking at the code, my understanding is that what the example does is get a data row and build an output string of HTML using any column from that data row along with any other arbitrary HTML you might care to use. In the example, the output is built up as a table, but if you really wanted to you could use whatever... it's just HTML being added to the DOM after all!

What I'm not sure about is this: in the example, only 1 of the data cells is being pushed into the details output. For my implementation I want almost ALL the columns from the aData object. Should I expect a performance hit doing it this way? I believe clone is a pretty efficient mechanism, but it's still adding objects to the DOM, which is never without a hit, and may begin to use up an abundance of resources given that I poll for new data every 3 seconds and in most cases my rows are going to be rebuilt.

I tend to use fnRowCallback as a crutch, and I think it would work here, too; building the complementary details box as the row is rendered.

Given that I poll so often and that the table and/or rows (only just now getting back to some previous advice you gave in that regard!) are almost always candidates for updating, can anyone recommend the zippiest option?

Thanks!

Replies

  • allanallan Posts: 63,522Questions: 1Answers: 10,473 Site admin
    I'd say that fnOpen and fnClose with something like fnFormatDetails will give you better performance and fnRowCallback since DataTables keeps a track of what rows are opened and closed internally, meaning you don't need to rebuilt the 'details' line every time the table is redrawn (having said that, it would work though). I doubt you'll see a significant hit on performance in any of the current generation of browsers when making the details more complex (the object data source options in DataTables 1.8 are particularly useful for this sort of thing, so you don't need to have hidden columns with the data you want to access).

    Regards,
    Allan
This discussion has been closed.