couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nitin Borwankar <>
Subject Re: Futon Improvements
Date Wed, 09 Sep 2009 21:16:54 GMT
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
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 (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"

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,


37% of all statistics are made up on the spot
Nitin Borwankar

On Wed, Sep 9, 2009 at 1:20 PM, Paul Davis <>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.

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