Easy to use, and makes working with complex JSON a snap.
The source is also available:
in my case I needed a library to use it in a web app.
bookmarked anyway for personal use :)
- Remove quotes from strings. They're already formatted differently.
- Remove array indices.
- Unescape strings.
The context and formatting should still be enough for devs, but I can't imagine quotes or indices do anything for nontechnical people.
e.g. ["\"foo\"","bar"] translates to:
the array indices I was thinking on having it as an option, I would like 'something' to make them standout as lists even when no index is displayed, any idea?
will open issues for both:
The problem is that for most people the technical and subtle difference between 4 and "4" does not have any meaning except that "the system" apparently differentiates for some reason. Subsequently they will (implicitly) attach some meaning to the difference, but, as they don't have a background in information, their understanding probably does not correspond with the reasons why you implemented this difference. For example, they could think that "4" means "about four", or "four is important", or "four", or whatever.
Unless the difference between "4" and 4 is or becomes relevant to the user, the user should be prevented to have to differentiate between the two. And "because the system asks for it" doesn't really make it relevant to most users.
I do understand the problem, of course. Without some function attaching meaning to the JSON fields, a program cannot know if a 4 has to be 4 or "4". That means you have to make a rule one way or the other. The question you should ask yourself is: which one is best in your situation given the audience you target. Possible rules:
- a numerical number on its own, however written, is interpreted as 4 instead of "4". So, "4", " 4", 4, " 4 " will all be interpreted as 4.
- all primitive fields are all strings. The program has to attach meaning to them. So, 4, "4", " 4", are all "4"
- there is a difference between "4" and 4. If you want the number, use 4, if you want the text four written in numericals, use "4".
>something more than color to avoid causing trouble to colorblind people I think it's a good idea.
I think what you have is decent. Bold for numbers. Italics for literals.
Making arrays stand out is tough. Perhaps you could do some zebra striping on arrays. Or use bullets outside of each array value that mimics a list?
someone pointed out on an issue that empty lists and empty objects can't be differentiated, so a solution that handles both would be cool.
question: why the github fear? :)
For me, it's about spacing efficiency (I can see more at once), formatting (e.g., italic is not as easy to read as roman faces), and color (green on grey? huh?).
But I've always been a fan of plain-text in general. I'd much rather use plain-text markdown than MS Word, or edit code in plain files as opposed to an IDE. Plain text, to me, is much more WYSIWIG than any GUI tool I've used. But I understand that not everyone thinks the same way.
Original firefox extension:
the lib from this article is more tailored for apps that want to display arbitrary json to a broad range of users. As someone asked, there are not many uses, but I have one in my web app (http://event-fabric.com/)
the next next step would be to provide in place edition with validation :)
Definitely! Take a look at http://createjs.org/--it will probably help (in fact, I've been using it for a different project and if I have time I might be submitting a pull request to you in the next week or so).
YAML is a superset of JSON, but as long as the YAML used to convert to JSON started as JSON, there shouldn't be a problem.
I always try to use the right tool for the job.
Where do you see this being used?
until now I was using a pretty printer but the result was too "technical" for non programmers to see (at least that's my opinion).
It's been baked into http://www.servicestack.net web service fx and lets you see a human readable view of every web service response when called from a browser (i.e. Accept:text/html).
It's also has dynamically sortable table rows and is also completely static/stand-alone. It's just a static template that wraps an embedded JSON response and converting it to HTML on the fly and injecting it the page (all client-side / use view-source).
Here's a live preview of it in action:
And the JSON service it's wrapping:
I was looking this morning at a lib to do this and I couldn't find one, but at one stack overflow question someone posted a screenshot of the ColdFusion tool and I said "that's what I need" and then I decided to do it myself.
now someone mentions it here, full circle :D
I created an issue for that:
also one to customize the display of booleans (sometimes on/off, yes/no are better than true/false)
I've used this library recently to help the QA's better understand a JSON API's output.
Edit: treeIt can be used also in Node, has tests written for it and you can customize the HTML template for it.
thanks, didn't know it was a bad practice.
JSON is easy to read, but can get hard to visually parse when the payload is large.
It's working (not done yet), but I've got an update on my local that I need to iron a bit before I commit.
Oh, and the name sucks.
It's funny, I didn't think it would be useful until I actually checked it out, because I personally find JSON to be fairly readable.
Maybe I'm not human. Captchas have been telling me this for a while.
that's the reason for this lib.
thanks for the awesome part :D
happy programmers day! :)
HN is like a free proof reader as a service :P
when two words have similar pronunciation I may write the wrong one.