couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nitin Borwankar <ni...@borwankar.com>
Subject Re: JSON Formatting [Forked: Futon Improvements]
Date Wed, 09 Sep 2009 21:53:07 GMT
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?

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.
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message