Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Table-to-JSON

lightswitch05.github.io

Post reply on HN
Print view View original

21–30 of 33 posts

Re: Table-to-JSON

#21

Post by ebiester »

bdg wrote: post #14

I'm having a hard time understanding why everyone's jazzed about this. When is this a useful thing to do? I've literally never once encountered a problem where this would be useful. I'm not trying to sound harsh, I just don't understand when I'd ever need to do something like this.

I had to do a version of this for myself a few weeks back in conjunction with datatables. We actually also use form elements in the table as well, which I had to handle as special cases. We'd then send the JSON back to the server, which would generate an Excel file.

Why not just send back to the server instead? First, sending the JSON back turned out to be faster than rerunning the query. Second, datatables has a full text search option which made things simpler for our case.

(Datatables has an export plugin, but it uses flash and only generates thinly-veiled CSV.)

So there's a use case for something like this.

Re: Table-to-JSON

#22

Post by ebiester »

JangoSteve wrote: post #10
rcfox wrote: post #5

It's a nice start to something that looks pretty useful. There are some things to consider though: What if you have headings as the first column in each row? What if you have headings in the first column, and the first row? Also, what is the use case for data overrides? In my opinion, it completely defeats the purpose when your intention is to take the contents of the table.

I've written a plugin that actually does this. I haven't had time to write the documentation yet, but our Dynatable plugin [1] has been in use for almost 2 years now. It's an alternative to the Datatables plugin. All its logic works on the set of data in JSON, so it first translates an html table into JSON, then vice versa. The cool thing about this process is, you can write your own translate step to easily work wit…

I'm curious -- what do you think the tradeoffs are for Dynatable versus Datatables?

Re: Table-to-JSON

#24

Post by bdg »

JangoSteve wrote: post #15
bdg wrote: post #14

I'm having a hard time understanding why everyone's jazzed about this. When is this a useful thing to do? I've literally never once encountered a problem where this would be useful. I'm not trying to sound harsh, I just don't understand when I'd ever need to do something like this.

This library is like a building block to e.g. building your own interactive table functionality. Let's say you have an HTML table, and you want to allow users to dynamically search or sort the table. Step 1 could be to translate the table to JSON, step 2 would be do all your JS magic on the JSON data set, and step 3 would be write it back to the table. This approach is cleaner than trying to do a bunch of logic on th…

I suppose that's my issue. Dynamically searching or sorting wouldn't require converting to JSON, I'd rather work with the existing table object:

tableName.rows[rowNum].cells[cellNum]

Instead of loading all of that into a variable (a second time, it's already an object on your page), trying to keep it in sync, binding events in both directions to keep it in sync, the load of doing twice the work, the lag of redrawing the entire table every time you want to do something, etc..

I don't see why this is cleaner than working on the DOM. I've done this a number of times and only found headaches when trying to build something larger than a silly toy or a list of 30 items on a table. IIRC DataTables did something like this internally last time I looked at it, and that thing konks out and either slows down your page or crashes the browser depending on how many cells you load into it.

Re: Table-to-JSON

#25

Post by bdg »

ebiester wrote: post #21
bdg wrote: post #14

I'm having a hard time understanding why everyone's jazzed about this. When is this a useful thing to do? I've literally never once encountered a problem where this would be useful. I'm not trying to sound harsh, I just don't understand when I'd ever need to do something like this.

I had to do a version of this for myself a few weeks back in conjunction with datatables. We actually also use form elements in the table as well, which I had to handle as special cases. We'd then send the JSON back to the server, which would generate an Excel file. Why not just send back to the server instead? First, sending the JSON back turned out to be faster than rerunning the query. Second, datatables has a ful…

Have you thought about sending the HTML of that data back instead of computing the JSON encoding? Your server side could actually parse the DOM and possibly preserve things like fonts/styles when loading into excel (I know how giddy managers get when their auto-generated reports have styles).

Re: Table-to-JSON

#26

Post by bdg »

rcfox wrote: post #5

It's a nice start to something that looks pretty useful. There are some things to consider though: What if you have headings as the first column in each row? What if you have headings in the first column, and the first row? Also, what is the use case for data overrides? In my opinion, it completely defeats the purpose when your intention is to take the contents of the table.

> There are some things to consider though

To add to your list, there is of course that old chestnut of "it doesn't support the full tables spec" (which in all fairness is quite complex).

Re: Table-to-JSON

#27

Post by JangoSteve »

terrahawkes wrote: post #19
JangoSteve wrote: post #12

Earlier quoted context omitted.

You could do what they're suggesting without being too clever. For instance, our dynatable plugin does it this way: table.find('thead tr').children('th,td') But it could easily be something like: var headings = table.find('thead th'); if (!headings.length) headings = table.find('th'); if (!headings.length) headings = table.find('tr:first td');

The HTML specification's algorithm for determining the applicable headers for a table cell might be useful: http://www.whatwg.org/specs/web-apps/current-work/multipage/... This was developed with reference to a corpus of real web tables.

I was actually really excited to read that, thinking I was going to implement it straight away in our plugin. But it seems to require scanning up the table from the current cell, for each cell, to get its header, and it also requires knowing the rendered height of the cell, which I don't fully understand. I'm sure if I actually sat down and wrote it out, it'd make more sense.

At any rate, it seems like trying to implement their algorithm verbatim in javascript would be pretty slow for large tables. Maybe it's better to just use it for inspiration.

Also, their algorithm seems to come at if from the perspective of, "I have a cell, what is its header?" It would be more efficient in reverse, if we could instead answering the question, "I have a header, what are its cells?". What dynatable does now is sort of a hybrid approach (we find the header cells, make a dictionary, then loop through the rows, assigning each cell value to its attribute in the dictionary). The issue is, according to that article, any table cell could potentially be a header cell, not just those in the header row or in th elements.

Re: Table-to-JSON

#28

Post by JangoSteve »

bdg wrote: post #24
JangoSteve wrote: post #15

Earlier quoted context omitted.

This library is like a building block to e.g. building your own interactive table functionality. Let's say you have an HTML table, and you want to allow users to dynamically search or sort the table. Step 1 could be to translate the table to JSON, step 2 would be do all your JS magic on the JSON data set, and step 3 would be write it back to the table. This approach is cleaner than trying to do a bunch of logic on th…

I suppose that's my issue. Dynamically searching or sorting wouldn't require converting to JSON, I'd rather work with the existing table object: tableName.rows[rowNum].cells[cellNum] Instead of loading all of that into a variable (a second time, it's already an object on your page), trying to keep it in sync, binding events in both directions to keep it in sync, the load of doing twice the work, the lag of redrawing…

I think the issue is that, if you are doing something like sorting, you actually are going to have to redraw the entire table.

Also, for things like plain-text searching, it's faster to do it on a collection of objects detached from the DOM in JavaScript than to scan the DOM, and especially if you're doing non-text comparisons (like comparing a number with the parseFloat representation of the values in one of the table columns for all rows).

And finally, if you are going to read and then redraw in the DOM, it's best to do it as grouped atomic operations due to the inefficiency making the browser reflow (https://developers.google.com/speed/articles/reflow).

For what it's worth, this is how Dynatable works internally, though I haven't had any issues with it being slow, though it's possible I just haven't used it with large enough data sets yet (I've only used it on tables of probably 1000 rows or less so far).

Re: Table-to-JSON

#29

Post by ebiester »

bdg wrote: post #25
ebiester wrote: post #21

Earlier quoted context omitted.

I had to do a version of this for myself a few weeks back in conjunction with datatables. We actually also use form elements in the table as well, which I had to handle as special cases. We'd then send the JSON back to the server, which would generate an Excel file. Why not just send back to the server instead? First, sending the JSON back turned out to be faster than rerunning the query. Second, datatables has a ful…

Have you thought about sending the HTML of that data back instead of computing the JSON encoding? Your server side could actually parse the DOM and possibly preserve things like fonts/styles when loading into excel (I know how giddy managers get when their auto-generated reports have styles).

In our case, we didn't want to send it all back, and we had our own style to enact on the server side. Sending back the HTML is perfectly fine (albeit a little larger) but as this is JSON, you could easily send back the style to the server if you so wanted.

Re: Table-to-JSON

#30

Post by lightswitch05 »

bdg wrote: post #14

I'm having a hard time understanding why everyone's jazzed about this. When is this a useful thing to do? I've literally never once encountered a problem where this would be useful. I'm not trying to sound harsh, I just don't understand when I'd ever need to do something like this.

Hey, great question! Well, I don't know why other people might need this plugin, but I needed to gather data from a dynamic user-editable table. Its not all that complicated getting data from an HTML table, but my specific table is dynamic in sense of how many column and rows are available. Also the heading names. I considered keeping track of the contents as the user edited it, but in the end it was just easiest to get the end result rather than keeping track of all the edits. So, thats where table-to-JSON came from. Had no clue so many people would be interested in such a simple plugin.
Post reply on HN