`pretty_tables` should return object that is `showable` as `"text/html"`

[clarkevans]

By default, if a pretty_table is rendered using HTML mode, it should probably return an object showable("text/html", ... ) that is, implementing Base.show(io::IO, m::MIME"text/html", ... ).

julia> x = pretty_table(String, rand(2,2); backend=:html, standalone=false);

julia> display("text/html", x)
ERROR: MethodError: no method matching show(::Base.TTY, ::MIME{Symbol("text/html")}, ::String)

julia> typeof(x)
String

Perhaps pretty_table(HTML, table) should do this?

julia> x = pretty_table(HTML, rand(2,2); standalone=false);
ERROR: The type UnionAll is not supported.

This topic came up as JuliaPluto/HypertextLiteral.jl#11

[ronisbr]

Hi @clarkevans !

Thanks! The development of the HTML backend was staled because I was working to stabilize the text backend due to DataFrames.jl. I really like the option to pass HTML (as we pass String) to return an object that can be rendered in HTML.

[ronisbr]

Hi @clarkevans

Can you please tell me why do you need this? pretty_table wraps the HTML output into a showable object if io == stdout. Why do you need to return a string and then show it?

Check this:

PrettyTables.jl/src/backends/html/print.jl

Line 363 in 921ade2

# If we are printing to `stdout`, then wrap the output in a `HTML` object.

[clarkevans]

@ronisbr

Can you please tell me why do you need this?

It's Julia's standard way of handling multimedia content. You should be able to use PrettyTables directly within Pluto.

pretty_table wraps the HTML output into a showable object if io == stdout. Why do you need to return a string and then show it?

At first glance, this design seems to be inventing your own multimedia handling.

Here's an idea. Have pretty_table(table) return a PrettyTable object, which is a deferred rendering. Then, dispatch show() on PrettyTable based on the mime type. Then, it could work directly within Pluto. If someone wants the string value, they can do string(pretty_table(table)). Thoughts?

[ronisbr]

I understand your idea. However, it goes to a very different direction from what I was thinking when designing PrettyTables.jl. I decided to make a package to render tables, not a table handler. Hence, packages like DataFrames.jl can use this backend. At those packages, this architecture you propose works fine. That's why I dislike the idea of returning a PrettyTable object.

At the end, you are printing some entity (an array, a data frame, etc.). Hence, you can always overload show to do what you want with this entity, calling the correct backend of PrettyTables.jl. Makes sense?

[ronisbr]

Btw, last time I checked, pretty_table(table, backend = :html) was providing a correct visualization of an HTML table in Pluto. Did it change?

[clarkevans]

Neither pretty_table(rand(2,2)) nor pretty_table(rand(2,2), backend = :html) work in Pluto. The latter form, specifying an HTML backend explicitly, should not be required since Pluto will try to show the return value to "text/html" by default. The return value of pretty_table in these cases is nothing, which, when shown to "text/html" displays produces nothing. The current behavior is to spew content to the console debug stream, where it's not helpful to the user.

Right now the current design is unwieldy for use in Pluto and other display systems that use Julia's standardized multimedia approach. I am only responding here since got a tech support ticket in my library, as referenced above.

[ronisbr]

pretty_table must be seen as print. It does not return an object because it was not meant to be a table handler. Its purpose is to render a table to an IO, which can be stdout, a file, etc. This multimedia system should be used when you have a type, like DataFrame, and want to show it. In this case, you might use pretty_table.

I need to investigate this further. I think Pluto.jl is using stdout for debugging. The HTML backend works fine in Jupyter:

[ronisbr]

Now I see why Pluto.jl is not working. It is the same reason why print(rand(10, 10)) does not work either. In this case, I really cannot change the default behavior because PrettyTables.jl was supposed to be a rendered to an IO. The easiest workaround is to do something like:

HTML(pretty_table(String, rand(10, 10), backend = :html))

We can discuss adding support for something like pretty_table(HTML, rand(10, 10)) that, in this case, will return an HTML object (just like pretty_table(String...) returns a String). What do you think?

[ronisbr]

Bump! :) Hi @clarkevans, do you think that solution pretty_table(HTML, ...) will work for you? In this case, should we force backend to be :html? If the user pass pretty_table(HTML, backend = :text) should we just ignore, show a warning, or throw an error?

[yha]

pretty_table must be seen as print. It does not return an object because it was not meant to be a table handler. Its purpose is to render a table to an IO, which can be stdout, a file, etc. This multimedia system should be used when you have a type, like DataFrame, and want to show it. In this case, you might use pretty_table.

The problem is that for show with a DataFrame, there's no good interface for providing the formatting options which pretty_table supports (such as nosubheader or tf). So the DataFrame needs to be wrapped in some "formatted DataFrame" type which includes this formatting information. I think it makes more sense to have this wrapper type in this package rather than in DataFrames, since it's quite a thin wrapper over the current pretty_table.
Of course, it could be in another separate package, but that seems like an unnecessary complication. Especially since end users would have little use for the low level pretty_table that prints to an IO once a version returning a showable exists.

[ronisbr]

Hi @yha,

I understood. I will implement that API passing HTML just as we have the String, returning an HTML object!

Just for your information, every option in pretty_table can be passed to show when printing a DataFrame:

julia> df = DataFrame(a = 1, b = 2, c = 3)
1×3 DataFrame
 Row │ a      b      c
     │ Int64  Int64  Int64
─────┼─────────────────────
   1 │     1      2      3

julia> show(df, tf = PrettyTables.tf_markdown, nosubheader = true, vlines = :all)
1×3 DataFrame
| Row | a | b | c |
|-----|---|---|---|
|   1 | 1 | 2 | 3 |

[ronisbr]

Done! Can you please test (using master)?

[ronisbr]

Now, the default (if nothing is specified) is to pass stdout as the first argument, which just writes to stdout. The other two options are String and HTML. We can revisit this in the future, to verify if there is a better default. However, I would like to keep the default as it is until I finish the integration with DataFrames.