Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #31953 > unrolled thread

Simply displaying JSON data for users: what is your preferred method?

Back to article view | Back to comp.lang.javascript

Contents

  Simply displaying JSON data for users: what is your preferred method? Doc O'Leary  <droleary@2015usenet1.subsume.com> - 2016-12-24 16:15 +0000
    Re: Simply displaying JSON data for users: what is your preferred method? JJ <jj4public@vfemail.net> - 2016-12-25 18:01 +0700
      Re: Simply displaying JSON data for users: what is your preferred method? $Bill <news@todbe.com> - 2016-12-25 15:40 -0800
        Re: Simply displaying JSON data for users: what is your preferred method? David Mark <dmark.cinsoft@gmail.com> - 2016-12-25 16:21 -0800
          Re: Simply displaying JSON data for users: what is your preferred method? $Bill <news@todbe.com> - 2016-12-25 19:36 -0800
            Re: Simply displaying JSON data for users: what is your preferred method? David Mark <dmark.cinsoft@gmail.com> - 2016-12-26 04:50 -0800
              Re: Simply displaying JSON data for users: what is your preferred method? $Bill <news@todbe.com> - 2016-12-26 15:08 -0800
                Re: Simply displaying JSON data for users: what is your preferred method? David Mark <dmark.cinsoft@gmail.com> - 2016-12-28 19:26 -0800
      Re: Simply displaying JSON data for users: what is your preferred method? JJ <jj4public@vfemail.net> - 2016-12-26 23:19 +0700
        Re: Simply displaying JSON data for users: what is your preferred method? JJ <jj4public@vfemail.net> - 2016-12-26 23:30 +0700
      Re: Simply displaying JSON data for users: what is your preferred method? Doc O'Leary  <droleary@2015usenet1.subsume.com> - 2016-12-26 16:27 +0000
    Re: Simply displaying JSON data for users: what is your preferred method? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-12-26 12:36 -0800

#31953 — Simply displaying JSON data for users: what is your preferred method?

I’m looking to avoid overwrought template frameworks; the idea is that 
I have a data-centric app that needs to display arbitrary JSON input, 
but do a bit more than just pretty print it.  I wouldn’t be opposed to 
*some* small amount of customization in the look for the more 
structured info, but it would need to come with low overhead and be 
easy to drop in for someone (like a research scientist) that doesn’t 
know a lot about HTML or JavaScript/JSON beyond the basic syntax.

My starting approach was to just drop a .toHTML() method on object 
prototypes that kicks out some appropriate markup (e.g., Array items 
become <li> elements).  It works well enough, but it’s already clear 
that I’m going to need to factor things out to some kind of framework 
if I want to get fancy.  Something straightforward must already exist!

No event hooks needed.  No $global objects for tricky manipulation of 
the DOM necessary.  No grand visions to transform JavaScript into a 
whole new language wanted.  I just have data that I want to make semi-
attractive in a web page.

If it scales *up* to those other things it’s probably a bonus, but 
I’m really hoping to find something that scales down.  I’ve found a 
couple likely candidates, but I’m wondering if there’s anything really 
popular on the small end of the scale, or must the framework starting 
point be a dependency on jQuery these days.

Thanks.

[toc] | [next] | [standalone]

#31954

On Sat, 24 Dec 2016 16:15:21 -0000 (UTC), Doc O'Leary wrote:
> I’m looking to avoid overwrought template frameworks; the idea is that 
> I have a data-centric app that needs to display arbitrary JSON input, 
> but do a bit more than just pretty print it.  I wouldn’t be opposed to 
> *some* small amount of customization in the look for the more 
> structured info, but it would need to come with low overhead and be 
> easy to drop in for someone (like a research scientist) that doesn’t 
> know a lot about HTML or JavaScript/JSON beyond the basic syntax.
> 
> My starting approach was to just drop a .toHTML() method on object 
> prototypes that kicks out some appropriate markup (e.g., Array items 
> become <li> elements).  It works well enough, but it’s already clear 
> that I’m going to need to factor things out to some kind of framework 
> if I want to get fancy.  Something straightforward must already exist!
> 
> No event hooks needed.  No $global objects for tricky manipulation of 
> the DOM necessary.  No grand visions to transform JavaScript into a 
> whole new language wanted.  I just have data that I want to make semi-
> attractive in a web page.
> 
> If it scales *up* to those other things it’s probably a bonus, but 
> I’m really hoping to find something that scales down.  I’ve found a 
> couple likely candidates, but I’m wondering if there’s anything really 
> popular on the small end of the scale, or must the framework starting 
> point be a dependency on jQuery these days.
> 
> Thanks.

GitHub.com would be the perfect place to search for such library.

Try searching for "convert json to html" then narrow it down to JavaScript
language.

Just guessing, but I think a regular expression based converter would be
more efficient and faster than object based. i.e. JSON string to HTML string
then slap it all together using innerHTML, instead of JSON objects to HTML
element objects.

[toc] | [prev] | [next] | [standalone]

#31956

On 12-25-16 15:19, Stefan Ram wrote:
> JJ <jj4public@vfemail.net> writes:
>> Just guessing, but I think a regular expression based converter would be
>> more efficient and faster than object based. i.e. JSON string to HTML string
>> then slap it all together using innerHTML, instead of JSON objects to HTML
>> element objects.
>
>   I believe that it should be quit difficult to properly parse
>   JSON source with regular expression.

I wrote a JSON parser in Perl using RE's and parsing out tokens which I then used
to create a Perl hash duplicating the JSON object - not that difficult code-wise
(maybe 500-600 lines including blanks), but haven't really checked the efficiency
of it.  I also wrote an ICS to JSON converter and a JSON pretty printer (maybe 100
lines ea) rather than writing another parser and then I run it through the JSON
parser.  I use them regularly to scrape web pages.

[toc] | [prev] | [next] | [standalone]

#31960

On Sunday, December 25, 2016 at 6:41:05 PM UTC-5, $Bill wrote:
> On 12-25-16 15:19, Stefan Ram wrote:
> > JJ <jj4public@vfemail.net> writes:
> >> Just guessing, but I think a regular expression based converter would be
> >> more efficient and faster than object based. i.e. JSON string to HTML string
> >> then slap it all together using innerHTML, instead of JSON objects to HTML
> >> element objects.
> >
> >   I believe that it should be quit difficult to properly parse
> >   JSON source with regular expression.
> 
> I wrote a JSON parser in Perl using RE's and parsing out tokens which I then used
> to create a Perl hash duplicating the JSON object - not that difficult code-wise
> (maybe 500-600 lines including blanks), but haven't really checked the efficiency
> of it.

How about the accuracy? In other words, I agree with Stefan Ram's assessment (though his post is oddly absent here on Google Groups).

[toc] | [prev] | [next] | [standalone]

#31961

On 12-25-16 16:21, David Mark wrote:
> On Sunday, December 25, 2016 at 6:41:05 PM UTC-5, $Bill wrote:
>
>> I wrote a JSON parser in Perl using RE's and parsing out tokens which I then used
>> to create a Perl hash duplicating the JSON object - not that difficult code-wise
>> (maybe 500-600 lines including blanks), but haven't really checked the efficiency
>> of it.
>
> How about the accuracy? In other words, I agree with Stefan Ram's assessment (though his post is oddly absent here on Google Groups).

The accuracy is as good as your code.  I've hit one or two unexpected
things that I fixed fairly quickly, but the more I use it the better
chance of hitting some odd cases (like unicode values etc).  The accuracy
is as good as my understanding of JSON object syntax.

[toc] | [prev] | [next] | [standalone]

#31969

On Sunday, December 25, 2016 at 10:36:35 PM UTC-5, $Bill wrote:
> On 12-25-16 16:21, David Mark wrote:
> > On Sunday, December 25, 2016 at 6:41:05 PM UTC-5, $Bill wrote:
> >
> >> I wrote a JSON parser in Perl using RE's and parsing out tokens which I then used
> >> to create a Perl hash duplicating the JSON object - not that difficult code-wise
> >> (maybe 500-600 lines including blanks), but haven't really checked the efficiency
> >> of it.
> >
> > How about the accuracy? In other words, I agree with Stefan Ram's assessment (though his post is oddly absent here on Google Groups).
> 
> The accuracy is as good as your code.

How very interesting! Was that a specific benchmark you aimed for or did it just turn out that way? BTW, which of my code is it as good as?

>I've hit one or two unexpected
> things that I fixed fairly quickly, but the more I use it the better
> chance of hitting some odd cases (like unicode values etc).

Yes. It certainly increases the odds of hitting a limitation or oversight.

> The accuracy
> is as good as my understanding of JSON object syntax.

And as good as my code. That's quite the one-two punch. Best of luck with it. :)

[toc] | [prev] | [next] | [standalone]

#31994

On 12-26-16 04:50, David Mark wrote:
> On Sunday, December 25, 2016 at 10:36:35 PM UTC-5, $Bill wrote:
>> On 12-25-16 16:21, David Mark wrote:
>>> On Sunday, December 25, 2016 at 6:41:05 PM UTC-5, $Bill wrote:
>>>
>>>> I wrote a JSON parser in Perl using RE's and parsing out tokens which I then used
>>>> to create a Perl hash duplicating the JSON object - not that difficult code-wise
>>>> (maybe 500-600 lines including blanks), but haven't really checked the efficiency
>>>> of it.
>>>
>>> How about the accuracy? In other words, I agree with Stefan Ram's assessment (though his post is oddly absent here on Google Groups).
>>
>> The accuracy is as good as your code.
                               ^^^^

> How very interesting! Was that a specific benchmark you aimed for or did it just turn out that way? BTW, which of my code is it as good as?

'your' meaning the generic coder (which in the above case was 'my' JSON parser not 'yours'). :)

>> I've hit one or two unexpected
>> things that I fixed fairly quickly, but the more I use it the better
>> chance of hitting some odd cases (like unicode values etc).
>
> Yes. It certainly increases the odds of hitting a limitation or oversight.
>
>> The accuracy
>> is as good as my understanding of JSON object syntax.
>
> And as good as my code. That's quite the one-two punch. Best of luck with it. :)

My understanding and my code - unless you write one and then it's your understanding
and code. :0

[toc] | [prev] | [next] | [standalone]

#32015

On Monday, December 26, 2016 at 6:08:31 PM UTC-5, $Bill wrote:
> On 12-26-16 04:50, David Mark wrote:
> > On Sunday, December 25, 2016 at 10:36:35 PM UTC-5, $Bill wrote:
> >> On 12-25-16 16:21, David Mark wrote:
> >>> On Sunday, December 25, 2016 at 6:41:05 PM UTC-5, $Bill wrote:
> >>>
> >>>> I wrote a JSON parser in Perl using RE's and parsing out tokens which I then used
> >>>> to create a Perl hash duplicating the JSON object - not that difficult code-wise
> >>>> (maybe 500-600 lines including blanks), but haven't really checked the efficiency
> >>>> of it.
> >>>
> >>> How about the accuracy? In other words, I agree with Stefan Ram's assessment (though his post is oddly absent here on Google Groups).
> >>
> >> The accuracy is as good as your code.
>                                ^^^^
> 
> > How very interesting! Was that a specific benchmark you aimed for or did it just turn out that way? BTW, which of my code is it as good as?
> 
> 'your' meaning the generic coder (which in the above case was 'my' JSON parser not 'yours'). :)

You seem to be pointing to "as good" in your bit that I quoted. Regardless, it was a very odd thing to say. Of course the accuracy of your code is down to... your code. :)

Guess it will remain a mystery as to how accurate it might be. But if it is based on regular expressions, my guess (and previous implication) is that it will have problems.

[toc] | [prev] | [next] | [standalone]

#31974

On 25 Dec 2016 23:19:30 GMT, Stefan Ram wrote:
> 
>   I believe that it should be quit difficult to properly parse
>   JSON source with regular expression.
> 
>   Here's a quick take at it. The code is not cleaned up and
>   contains unnecessary parts and is incomplete and possibly
>   fails to properly recognize an array. It is a draft of how I
>   might do this (the linewidth of the source code is about 132).
>   It was edited just before posting it without testing it again.
[snip]

You're right. It's too difficult.

I ended up writing my own function since I might need it myself.
The function accepts an object and returns a HTML code.
The rendered HTML code is parseable (so far).
I tested it with JSON from https://api.reddit.com/

function objToHtml(obj, next, inArray) {
  //next and inArray arguments are for internal use only
  var res = "", count = 0, i;
  function strEscape(s) {
    return s.replace(/\t/g, '\\t').replace(/\n/g, '\\n').
      replace(/</g, '&lt;').replace(/>/g, '&gt;').
      replace(/"/g, '\\&quot;').replace(/'/g, '\\&apos;').
      replace(/&/g, '&amp;').;
  }
  if (Array.isArray(obj)) {
    res = obj.reduce(function(prev,cur) {
      return prev + '<li>' + objToHtml(cur, true, true) + '</li>,\n';
    }, "");
    if (obj.length || !next) {
      res = '<ol class="' + (next ? "" : "json ") + 'array">[ <span>/* ' +
        obj.length + ' elements */</span>\n' +
        res.substr(0, res.length-2) + '\n]</ol>\n';
    } else {
      res = '[ ]\n';
    }
  } else {
    for (var key in obj) {
      count++;
      if (typeof obj[key] !== "object") {
        if (typeof obj[key] === "string") {
          res += '<div class="prop ' + (typeof obj[key]) + '">"' + key +
            '" : "' + strEscape(obj[key]) + '", <span>/* ' +
            obj[key].length + ' characters */</span></div>\n';
        } else {
          res += '<div class="prop ' + (typeof obj[key]) + '">"' + key +
            '" : ' + obj[key] + ',</div>\n';
        }
      } else if (Array.isArray(obj[key])) {
        res += '<div class="prop array">"' + key + '" : ' +
          objToHtml(obj[key], true) + ',</div>\n';
      } else {
        res += '<div class="prop object">"' + key + '" : ' +
          objToHtml(obj[key], true) + ',</div>\n';
      }
    }
    if (count) {
      i = res.lastIndexOf(',');
      if (i) {
        res = res.substr(0, i) + res.substr(i+1);
      }
    }
    if (count || !next) {
      res = '<div class="' + (next ? "" : "json ") +
        'object">{ <span>/* ' + count + ' properties */</span>\n' + res +
        '}</div>\n';
    } else {
      res = '{ }\n';
    }
  }
  if (next) {
    return res;
  } else {
    return '<style>.json div>div{margin-left:2ex} .json span{color:#777} \
.json ol{margin:0} .json li>div{margin-left:2ex} \
.json .object{background:#eee} .array{background:#ddf} \
.string{background:#fdd} .number{background:bdb} \
.boolean{background:#dbd}</style>\n' + res;
  }
}

[toc] | [prev] | [next] | [standalone]

#31976

On Mon, 26 Dec 2016 23:19:52 +0700, JJ wrote:
>   function strEscape(s) {
>     return s.replace(/\t/g, '\\t').replace(/\n/g, '\\n').
>       replace(/</g, '&lt;').replace(/>/g, '&gt;').
>       replace(/"/g, '\\&quot;').replace(/'/g, '\\&apos;').
>       replace(/&/g, '&amp;').;
>   }

Oops. Typo. Has dangling "." character at end. It should be:

   function strEscape(s) {
     return s.replace(/\t/g, '\\t').replace(/\n/g, '\\n').
       replace(/</g, '&lt;').replace(/>/g, '&gt;').
       replace(/"/g, '\\&quot;').replace(/'/g, '\\&apos;').
       replace(/&/g, '&amp;');
   }

[toc] | [prev] | [next] | [standalone]

#31975

For your reference, records indicate that 
JJ <jj4public@vfemail.net> wrote:

> GitHub.com would be the perfect place to search for such library.

Like I said, I’ve already searched and have some options, but I’m 
wondering what other people might recommend.  Just because someone 
threw up a personal project they started 3 years ago on GitHub does 
*not* make it worthy of anyone’s attention.  The lack of curation 
has become a real problem with the open source community.

> Just guessing, but I think a regular expression based converter would be
> more efficient and faster than object based. i.e. JSON string to HTML string
> then slap it all together using innerHTML, instead of JSON objects to HTML
> element objects.

I don’t care about fast at this point.  I care about smallish and 
simple.  If someone can barely get a handle on HTML and JSON, I’m not 
about to ask them to start doing convoluted regex parsing.

What I’m essentially looking for is something like the CSS Zen Garden.  
Just like CSS associates styles with the underlying HTML, I want to 
associate *that* HTML with some underlying JSON in a sufficiently 
generic way that people can, if they don’t like the default, easily 
tweak the output so that it makes the most sense to them.

-- 
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly

[toc] | [prev] | [next] | [standalone]

#31987

On Saturday, December 24, 2016 at 10:16:56 AM UTC-6, Doc O'Leary wrote:
> I’m looking to avoid overwrought template frameworks; the idea is that 
> I have a data-centric app that needs to display arbitrary JSON input, 
> but do a bit more than just pretty print it.  I wouldn’t be opposed to 
> *some* small amount of customization in the look for the more 
> structured info, but it would need to come with low overhead and be 
> easy to drop in for someone (like a research scientist) that doesn’t 
> know a lot about HTML or JavaScript/JSON beyond the basic syntax.

Perhaps something declarative and simple as data-foo hooks on html tags.

For example:

<script type="text/javascript">
var myData = new MyDataSource({
    columns: ['Element','Symbol'],
    data: [
        ['Hydrogen','H'],
        ['Helium','He'],
        ['Lithium','Li'],
        ['Beryllium','Be'],
        ['Boron','B'],
        ['Carbon','C'],
        ['Nitrogen','N'],
        ['Oxygen','O'],
        ['Fluorine','F'],
        ['Neon','Ne']
    ]
})
</script>

...

<table data-src="myData"></table>

which becomes:

<table>
<thead><tr><td>Element</td><td>Symbol</td></tr></thead>
<tbody>
<tr><td>Hydrogen</td> <td>H</td></tr>
<tr><td>Helium</td> <td>He</td></tr>
<tr><td>Lithium</td> <td>Li</td></tr>
<tr><td>Beryllium</td> <td>Be</td></tr>
<tr><td>Boron</td> <td>B</td></tr>
<tr><td>Carbon</td> <td>C</td></tr>
<tr><td>Nitrogen</td> <td>N</td></tr>
<tr><td>Oxygen</td> <td>O</td></tr>
<tr><td>Fluorine</td> <td>F</td></tr>
<tr><td>Neon</td> <td>Ne</td></tr>
</tbody>
</table>

And a possibility for more control:

<table data-src="myData">
<thead><tr><td>Element</td><td>Symbol</td></tr></thead>
<tbody>
<tr><td><div data-field="Element"></div></td>
<td><div data-field="Symbol"></div></td></tr>
</tbody>
</table>

I think this idea is simplistic enough for an easy learning curve, and also suggestive of other things you could do to build on the concept

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web