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 [email protected] On Wed, Sep 9, 2009 at 2:31 PM, Paul Davis <[email protected]>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 ™. > 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<[email protected]> > 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 > > [email protected] > > > > > > On Wed, Sep 9, 2009 at 1:20 PM, Paul Davis <[email protected] > >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. > >> > > >
