On Wed, Sep 9, 2009 at 2:53 PM, Nitin Borwankar<[email protected]> 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 > [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. >> >> >> > >> > -- Chris Anderson http://jchrisa.net http://couch.io
