Add ability to write out the interactive HTML table with javascript to disk - #2875

I'm working on this to see how easy it is to do

Ok so the code here implements with minimal changes:

t.write('table.html', format='jsviewer')

To-dos:

• Avoid duplication of writing out the HTML inside the jsviewer writer and use t.write(..., format='html') instead since it can write to a file object.
• Get show_in_browser() (without jsviewer) to work again - somehow the HTML file writing is failing
• Implement the include_js_files=True option which writes out the js files alongside the HTML table. Actually we also need to write out the CSS files.

Want to take over @keflavich? :)

I guess that's okay. I mean, to me it seems something easy enough for the web browser to just do, but I could also imagine this being useful to write this format out without having to invoke a browser.

@embray - this could be handy if e.g. running on a Django instance and generating a table on-the-fly

Just needs a "new features" changelog entry 👍

This is now ready for review and testing.

@taldcroft @AmrAS1 - this implements a few changes to the html writer in io.ascii, so could you review this? The changes are the addition of the js, cssfiles and jsfiles options.

@keflavich @embray @mdboom - the jsviewer now defaults to using remote versions of the js and css files since that is likely to be the desired behavior when writing out using the jsviewer writer. I've then set show_in_browser to request that the local files are used instead. It seemed more natural that way around. Does this seem ok?

@keflavich - how is the notebook version meant to be used? Also, since you wrote the original version of this, can you review this PR?

To try this out, load up a table then do:

t.write('test.html', format='jsviewer')

then open the test.html file in a browser.

Note to self: add tests!

io.ascii.HTML changes look fine to me.

@AmrAS1 @taldcroft - one thing I was curious about, is why the HTML writer takes a dictionary of options rather than taking the options directly. Is there a reason for this design choice?

@astrofrog - When I wrote the HTML class I figured I would replicate the behavior of the LaTeX writer (which accepts a parameter latexdict). I assume the reasoning behind using this style is what was discussed in #2716 for the change to fast_reader -- that we don't want read() cluttered with format-specific parameters.

Looks good as far as I can tell. My memory about the jsviewer is a bit spotty, though, so I can't promise that my review did any good. Still, it's a great idea and I'm sure I'll test it - I think this will be a great way to share some astroquery results with colleagues, and maybe a sensible way to locally save my most commonly performed ones.

@AmrAS1 - Ah I see - I had assumed that any parameters passed to read would just be passed to the specific formats. I don't mind either way :)

Actually extra parameters passed to read() will get to the specific Reader class, so they don't necessarily need to be encased in a dict. The HTML design was definitely influenced by the Latex reader. If I had a choice to re-do then I think I would not use a dict container arg, but it's not the end of the world.

@taldcroft - ok, no problem. Do you want to review this PR? If Travis passes then it can be merged.

Seems like there should be at least one unit test for the new HTML writer capability testing the three new htmldict options.

Apart from my comments this looks good.

The HTML/js table output from format='jsviewer' is fine, but somewhat heavy for my taste. Is it possible to get a table output which is something like http://mottie.github.io/tablesorter/docs/index.html with a single call to the io.ascii HTML writer? That would be nice for a documentation example or tutorial snippet, but not required for this PR.

@taldcroft - the look of the table can be completely controlled by the CSS file, so it's just a matter of swapping the CSS file URL which can be done by a configuration item. If we find a style we like better, such as the one you pointed out, we can always host the CSS file ourselves if it doesn't already exist somewhere reliable.

I'd rather leave that kind of improvement to a CSS wizard ;) For now, this uses a similar style to show_in_browser, but I'm +1000 on having a sleeker look.

OK. I was more referring to all the "cruft" in the upper and lower grey bars (Show 50 rows, search, etc) which is irrelevant for small-ish tables. I just want the option of an unadorned sortable table.

@taldcroft - I agree, we can make these things controllable by options. I'd rather leave that for a separate pull request, but I agree they should be done! :)

I will merge this later this evening if there are no objections, and will then open an issue to remind us to try and improve the CSS for the table view (could be done as a starter project)