> > Could you clarify? A request for…? > > Good gawd prettyboy where were you when they were handing out the smarts ?
Development request refers to Pauls post titled Futon Improvements ...maybe its closed already in @dev? ...either way for you cut and paste follows: from Paul Davis <[email protected]> reply-to [email protected] to [email protected], [email protected] date Thu, Sep 10, 2009 at 6:20 AM subject Futon Improvements mailing list <user.couchdb.apache.org> Filter messages from this mailing list mailed-by couchdb.apache.org Sep 10 (4 days ago) 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. Noah Slater, http://tumbolia.org/nslater >
