incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <jch...@apache.org>
Subject Re: JSON Formatting [Forked: Futon Improvements]
Date Wed, 09 Sep 2009 22:01:30 GMT
On Wed, Sep 9, 2009 at 2:53 PM, Nitin Borwankar<nitin@borwankar.com> wrote:
> Err we are not forking the JS spec, nor are we forking the JSON spec - we
> are specifying BibJSON a specific kind of JSON compliant format.It is
> perfectly within bounds for the BibJSON spec to require that the specific
> sub-class of JSON that is BibJSON have a certain serialization *as long as
> the serialization does not cause it to become non-compliant JSON or
> JS*. Yes?

Nitin,

I'd suggest you'd be better off leaving white-space concerns out of
your spec - you're just gonna end up being nominally incompatible with
all the JSON everyone emits. Pretty-printing should be handled by the
clients, not the servers.

There are Firefox plugins to pretty print JSON.

https://addons.mozilla.org/en-US/firefox/addon/10122
https://addons.mozilla.org/en-US/firefox/addon/10869

I like to run my JSON through http://jsbeautifier.org/ which does a
pretty good job even with long strings.

I agree that it'd be nice if CouchDB made it easier to edit functions
and JSON in the browser. I've been thinking for a long time of
building a CouchApp to edit CouchApps. I should really just get around
to this now.

Chris

>
> As I mentioned it passes JSLint, in fact JSLint gives it a pat on the back
> with "JSON: Good".
>
>
> 37% of all statistics are made up on the spot
> -------------------------------------------------------------------------------------
> Nitin Borwankar
> nborwankar@gmail.com
>
>
> On Wed, Sep 9, 2009 at 2:31 PM, Paul Davis <paul.joseph.davis@gmail.com>wrote:
>
>> Nitin,
>>
>> I don't think I'd place this in the Futon improvement category, but
>> access to controlling the pretty printing of JSON returned by couch.js
>> and jquery.couch.js doesn't sound out of the question assuming
>> json2.js supports it. I know Futon does it in source tabs, but I'm not
>> sure how.
>>
>> As to *requiring* specific whitespace, that'd be a Bad Idea &trade;.
>> Forking the JS specification like that would just cause you more
>> confusion than not. Configuring your apps to only output
>> pretty-printed JSON is a personal taste issue I think and not at all
>> incompatible with the spec.
>>
>> Also, s/\n/<p>/ == not so much. I'd be ok with pretty print functions,
>> but mutation beyond parse-ability seems not good. If you're looking to
>> include pretty printed json inside HTML, i'd suggest wrapping the
>> pretty printed version in a <pre />
>>
>> HTH,
>> Paul Davis
>>
>> On Wed, Sep 9, 2009 at 5:16 PM, Nitin Borwankar<nitin@borwankar.com>
>> wrote:
>> > Hi Paul,
>> > Re: formatting of JSON strings in general there have been some
>> discussions
>> > at my "day job" where we are working on a JSON rendering of BibTeX data
>> >  (currently called BibJSON by us).
>> >
>> > The annoying issue that comes up for us in human interactions with  a
>> JSON
>> > string (i.e. when JSON is in a disk file or on the screen, rather than
>> being
>> > munged by a browser) is that it is one interminably long string as there
>> are
>> > no \n's for pretty printing.
>> >
>> > So the BibJSON spec is considering doing something drastic ( there is
>> > understandable opposition to this and I am on the fence) such as
>> insisting
>> > that
>> > serialized BibJSON be formatted as
>> >
>> > [
>> >  {...},
>> >  {...},
>> >  {...}
>> > ]
>> >
>> > where there is an implicit \n after each of '['  ']' and '}' and after
>> every
>> > ',' so that it renders as above.
>> >
>> > Aside from visual rendering this way this approach is also useful when
>> doing
>> > some thing like 'head' or 'grep' on a file containing JSON.
>> > Ever try doing that on a '\n' less JSON file that is a few 10's of MB?
>> > For the uninitiated it gives you the whole friggin' file as a response to
>> > 'head' or 'grep' which is useless.
>> >
>> > BTW the above serialization with superfluous \n's, validates just fine in
>> > Doug Crockford's JSLint service http://jslint.com (note: 'jslint will
>> hurt
>> > your feelings' (TM) )
>> >
>> > So aside from how Futon handles JSON strings I would suggest some thought
>> to
>> > the value of
>> > a) a convention of adding \n's for human friendliness (even if just in
>> > files, in a couchapp tree)
>> > b) adding two methods to CouchDB's built in JS libraries that pretty-up
>> and,
>> > well,  ugly-up a JSON string.
>> > c) adding two methods that resp. replace \n with <p> and v.v in "JSON"
>> > strings
>> >
>> > This JSON string infrastructure support will make life much easier in
>> Futon,
>> > couchapp and other places where humans need to see/poke/prod JSON while
>> > working with CocuhDB.
>> >
>> > Aside from this, for Futon specific things, I would like to add my +1 to
>> the
>> > need for displaying/editing just one view function when you click on it
>> > rather than all of them all at once in one large bowl of insufferable
>> JSON
>> > stringy noodle soup that is served up right now.  I don't like JSON
>> noodle
>> > soup.  Dear Abby, am I the only one?
>> >
>> > Thanks much,
>> >
>> > Nitin
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > 37% of all statistics are made up on the spot
>> >
>> -------------------------------------------------------------------------------------
>> > Nitin Borwankar
>> > nborwankar@gmail.com
>> >
>> >
>> > On Wed, Sep 9, 2009 at 1:20 PM, Paul Davis <paul.joseph.davis@gmail.com
>> >wrote:
>> >
>> >> Hey everyone,
>> >>
>> >> So I'm at a bit of an impasse. I've got a couple ideas for how to give
>> >> Futon an extra bit of polish but I have no AJAX-fu. I thought I'd just
>> >> throw out some ideas and see if anyone wanted to try implementing
>> >> them. So, in no particular order:
>> >>
>> >> * Editing design doc functions. The current view editors are awesome
>> >> for a "create design doc" work flow, but there's a bit of a disconnect
>> >> when you want to edit an existing function. When viewing a design doc,
>> >> an edit link that would load that view in the editor would be cool.
>> >>
>> >> * Displaying functions in the Fields tab. It'd be nice to see if we
>> >> can make functions formatted a bit more nicely than just a plain
>> >> string as they are now. I'm not sure how well this would look, but
>> >> some smarts couldn't hurt.
>> >>
>> >> * Closely related to the previous point is truncating large strings in
>> >> the fields tab. There's a source tab now so we can just let people
>> >> click that if they're wanting to see something all gigantic.
>> >>
>> >> * Editing show/list functions. This is a big one, but something
>> >> similar to the view editor would be nice for editing lists and shows.
>> >> With similar edit links as above. I'm thinking that where we have view
>> >> rows output, we could just put up the view response as plain text and
>> >> then use the "raw view" button as a link to the live page.
>> >>
>> >> * Simple syntax checking before doing a save or run of functions.
>> >> Throw an error if you can't compile the function locally. This could
>> >> be combined with the next idea.
>> >>
>> >> * Function testing. This has been brought up before, but an
>> >> interesting thing to look into for editing views and lists would be to
>> >> have the browser fetch some subset of the db for testing. I'm not sure
>> >> on the best way to do this right now as it could be domain specific.
>> >> I'm thinking something like, create a filter function that can run
>> >> over _changes or a view and will select just some of the docs. Ideally
>> >> this would replace temporary views completely.
>> >>
>> >> * Frickin tab support in the function editing boxes.
>> >>
>> >> * Delete Test Suite DB's - A button on the test suite page that will
>> >> clean out the test suite db's. I tend to be OCD and going through and
>> >> deleting the test suite dbs gets old.
>> >>
>> >> * Test editing - When you click a test name the browser opens a new
>> >> window showing the source code of that test. If we instead opened a
>> >> new tab that had the function source loaded into the custom test
>> >> editor that'd be cool.
>> >>
>> >> * A selectable group_level or group=false on the view pages. And we
>> >> should probably change the default output in futon to a single row as
>> >> that's a constant confusion factor for new people.
>> >>
>> >> * Create/Delete config section/key/value triplets.
>> >>
>> >> * Raw view buttons for the config and status pages
>> >>
>> >> * Remember the Fields/Source tab preference
>> >>
>> >> * Another thing I'm just noting with the rest is that an interface for
>> >> setting up continuous replication is needed. Adam's still working on
>> >> some of the mechanics that will be required in the end, but some sort
>> >> of trigger for the existing functionality would be good.
>> >>
>> >> * View compaction button.
>> >>
>> >> * View info view (err, view of the info about a view)
>> >>
>> >> That's all I can think of right now.
>> >>
>> >> In terms of implementation, I'd take the well known URL approach.
>> >> Treat things on _design docs that are supposed to be functions as
>> >> functions and everything else is a string.
>> >>
>> >> Also, I'm not completely helpless here. If you're a webdev and have
>> >> been discouraged by the requirement of needing to build all of CouchDB
>> >> just to have a decent environment for editing some html and
>> >> javascript, let me know and I'll put together a small script so you
>> >> can run a local web server to hack on those pages more easily. The
>> >> basic work flow could then just be to svn co the share/www directory
>> >> and then point the server at it (assuming a running couchdb instance).
>> >> Just let me know if you're interested and I can cook that up pretty
>> >> quick.
>> >>
>> >> Thanks,
>> >> Paul Davis
>> >>
>> >> p.s. I double posted to include user@ to cast as wide of a net as
>> >> possible. If you're not on dev@ I invite you to join up and continue
>> >> this discussion there.
>> >>
>> >
>>
>



-- 
Chris Anderson
http://jchrisa.net
http://couch.io

Mime
View raw message