Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.210.185 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:cc:content-type
         :content-transfer-encoding;
        b=vwvq6+QeEiurZdaUmDtgdHuWZ9ayxvmgXE9SBX2uFkdzcJ0DMigJEF4ye1zfdwNzqe
         Or9mBepK0+5Id3nyD2bCXleG/LJ7EvftS5ezeXbaQtyWejvXGUPI/VwRP8ROjJBJhZyY
         Ul6AEO1iFsopMJufrgNmzi1ee1Yp/Vd3vEXuw=
MIME-Version: 1.0
Date: Wed, 9 Sep 2009 17:31:49 -0400
Message-ID: <e2111bbb0909091431p60d16e37sa0587e848fcb81e1@mail.gmail.com>
Subject: JSON Formatting [Forked: Futon Improvements]
From: Paul Davis <paul.joseph.davis@gmail.com>
To: dev@couchdb.apache.org
Cc: nitin@borwankar.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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>/ =3D=3D 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 discussion=
s
> at my "day job" where we are working on a JSON rendering of BibTeX data
> =A0(currently called BibJSON by us).
>
> The annoying issue that comes up for us in human interactions with =A0a J=
SON
> string (i.e. when JSON is in a disk file or on the screen, rather than be=
ing
> 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 insistin=
g
> that
> serialized BibJSON be formatted as
>
> [
> =A0{...},
> =A0{...},
> =A0{...}
> ]
>
> where there is an implicit \n after each of '[' =A0']' and '}' and after =
every
> ',' so that it renders as above.
>
> Aside from visual rendering this way this approach is also useful when do=
ing
> 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 hur=
t
> 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 a=
nd,
> well, =A0ugly-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 Fut=
on,
> 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 JSO=
N
> stringy noodle soup that is served up right now. =A0I don't like JSON noo=
dle
> soup. =A0Dear 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>w=
rote:
>
>> 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=3Dfalse 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.
>>
>