HTML output issues

[awesome-print]

HTML output issues

[michaeldv]

Hi,

So instead of

[pre]
hello\n
world\n
[/pre]

are you suggesting

[pre]hello[/pre]
[pre]world[/pre]

Is that right?
Michael

Michael, this is the contrary. With current version we get your second block. We should get the first one instead.

I made a few tests. To make it work properly, we need to:

1. Replace all the PRE tags with SPAN tags (to keep the colorizing feature)
2. Enclose the whole string, at the end, within one PRE tag (to keep the whitespaces etc.)

[rgabo]

I tried to use awesome_print to prettify hashes I display in a Rails 3 view, and I can only +1 @skunkalex's suggestion. A single pre tag with span tags with colors would do the trick, although I haven't had the time to try it out yet.

[michaeldv]

Fixed in michaeldv/awesome_print@3849b4a - is going to be part of upcoming 1.0 release.

[michaeldv]

Please check out the latest v1.0.1 ;-)

[XULRunner42]

I think it's still not quite right... I'm printing an array that contains hashes and the whole array is enclosed in

[pre]

but so are all of the sub-hashes. The net effect is to add too many blocks and nullify the indenting that was done in the context of the top-level <pre> node, so everything is forced to left aligned except for the array indices. I'm using ai to get my awesomeprinted recordset from a sqlite3 database as html:

def rows
  [email protected]("select * from to_document limit 7")
  recordset.ai(:html => true)
end

and printing it from a sinatra template of the mustache variety without HTML escaping...

{{{rows}}}

Any help you can offer is appreciated! I'm about to have a look at ai and see if I can figure out why it's putting in all of those extra <pre> tags that don't belong.

[XULRunner42]

From the spec file, it looks like this was never considered. HTML of nested arrays is just going to nest <pre> tags indefinitely...

[XULRunner42]

I am compelled to find a way to XSLT <pre> <pre>__ text</pre></pre> into <pre> __ text</pre>

Since I see the solution depends on :html=true to place the <pre> tags around each call in to format, but also to do the HTML escaping. If I could find the place where this code is called into from, I would be able to say if we can split those up into two options for recursive purposes.

If I'm talking in circles...

Recursed calls to format should not be printing more <pre> tags around their output like the top-level call (there is no sense in nesting <pre> nodes), but they should continue html escaping, so it's no good to just set :html=false when you're done with that.

Maybe I can find an elegant way to fix it...

[michaeldv]

Could you write a quick spec(s) with the expected results? I kind of understand where you're coming from but it sounds like we have the requirements that need some clarification.

[yebyen]

Sure! (same guy)

I'll post the spec in a second, but here's the incorrect output just so we're looking at the same thing:

require 'awesome_print'
markup = [ { "hello" => "world" }, { "goodbye" => "indents" } ]
puts markup.ai(:html => true)

(output)

<pre>[
    <kbd style="color:white">[0] </kbd><pre>{
        <pre>&quot;hello&quot;</pre><kbd style="color:slategray"> =&gt; </kbd><pre><kbd style="color:brown">&quot;world&quot;</kbd></pre>
    }</pre>,
    <kbd style="color:white">[1] </kbd><pre>{
        <pre>&quot;goodbye&quot;</pre><kbd style="color:slategray"> =&gt; </kbd><pre><kbd style="color:brown">&quot;indents&quot;</kbd></pre>
    }</pre>
]</pre>

[yebyen]

now, the spec:

it "does not try to nest <pre> tag deeper than one level" do
  markup = [ { "hello" => "world" }, { "goodbye" => "indents" } ]
  markup.ai(:html => true).should == <<-EOS.strip
<pre>[
    <kbd style="color:white">[0] </kbd>{
        &quot;hello&quot;<kbd style="color:slategray"> =&gt; </kbd><kbd style="color:brown">&quot;world&quot;</kbd>
    },
    <kbd style="color:white">[1] </kbd>{
        &quot;goodbye&quot;<kbd style="color:slategray"> =&gt; </kbd><kbd style="color:brown">&quot;indents&quot;</kbd>
    }
]</pre>
EOS
end

When the <pre> tags are distributed this way, everything looks as it should.

[denishaskin]

I've got a commit on my fork that addresses this: b1b8dd1

Someone want to take a look, and if it looks good I can submit a pull request? I did add @yebyen 's spec, modified the existing HTML spec, and it passes.

[XULRunner42]

Oh good :) I'll take a look if nobody gets around to it faster

[denishaskin]

Made actual pull request: https://github.com/michaeldv/awesome_print/pull/78

[michaeldv]

Hi Denis,

Thanks for the pull request! I'm going to get back to you after I review the proposed changes.

Michael

[XULRunner42]

It's much better now! I would say the only problem is the choice of white as the default color for array indices. My example is readable on a background of CornflowerBlue. Some of the colors you picked probably wouldn't be. What background would you recommend for color html output with the default colors?

[XULRunner42]

Also, how does one learn about the awesome inspector? I myself know about it because I found this post (where I myself had posted about it, so I must have learned it from somewhere), but it's not mentioned in the docs at all, and it's very hard to find any information about it using Google.

A minor nit, it's there in the code, I guess I read the spec and followed the example. The Kernel is pretty small. You could mention it in the README, today (as once before) it's exactly what I need.