couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Lenz <>
Subject Re: Futon Improvements
Date Thu, 10 Sep 2009 21:48:00 GMT
On 09.09.2009, at 22:20, Paul Davis wrote:
> * 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.

Personally, I don't view design docs in Futon much, and just use the  
view selector to edit views. But I guess a neat shortcut from the  
design doc to the view editor wouldn't hurt.

> * 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.

This is part of a general frustration I have with using Futon to read  
or even edit large strings, be they functions or blog post content or  
whatever. Futon just uses the raw JSON encoding, which means you get  
\n instead of line breaks, you need to escape double quote characters  
in the content, etc.

It'd be nice if we could just view and edit strings as text, but then  
the problem is: how do you enter non-string types (e.g. numbers or  
booleans)? We'd probably need a separate type selector of some kind,  
and I haven't yet had any bright idea on how to make that elegant and  
sufficiently efficient. An other option would be to treat anything  
that isn't parseable as JSON as a string, but then you'd need to enter  
"42" or "true" (with the quotes) to force a JSON parseable value to a  
string. Hmm. Might work though.

> * 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.

Agreed. That one should be pretty simple, too.

> * 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.

As I'm not a CouchApp/show/list user (yet?) I'll abstain about this  
feature. But I think adding it to database.html and  
$.futon.DatabasePage would likely overwhelm that part of the Futon  
code, so preferrably this would be in a separate area of some kind.  
But maybe I'm overestimating the amount of code this would take. IIRC  
there's a patch for this in JIRA that I haven't looked at yet.

> * 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.

I tried that at one point, but (a) it only works for Javascript views,  
and (b) it only works when the Javascript interpreter in the browser  
actually supports the features you're using in the view code. So you'd  
be getting pretty bad results when using E4X or some of the  
SpiderMonkey extensions not in the ECMAScript 3 standard. It'd be a  
dismissable warning at best, and that would be pretty annoying for  
people using such extensions. [I get these kind of erroneuos warnings  
for stuff *I know is perfectly fine* from VisualStudio all the time  
during working hours. Very annoying]

I think it'd be *way* better if CouchDB itself had a way to report  
actual syntax/compilation errors in view (or other) code. Futon could  
use that and relay any error messages to the user. Better runtime view  
error reporting would be nice, too.

> * 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.

I'm not sure I like this idea. IMO its value is limited because you're  
not testing the real thing.

> * Frickin tab support in the function editing boxes.

Would that insert tabs or spaces? And what indentation level should be  
used? :P J/K

Seriously, that would be nice. And it should be pretty darn simple to  
implement. Where's the JIRA issue? ;)

> * 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.

How would Futon know which databases can be deleted? The tests would  
probably need to register any disposable databases they create for  

> * 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.

Great idea. Shouldn't be hard, either.

> * 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.

I'd love this but simply haven't figured out a nice way to get this  
into the UI. Ideas welcome! (but for a *nice* way, not *some* way ;)

> * Create/Delete config section/key/value triplets.

Yes please :) Definitely not easy, though.

> * Raw view buttons for the config and status pages

Would be nice, and simple.

> * Remember the Fields/Source tab preference

Ditto. I actually thought we had that already. Hmm.

> * 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.

I haven't followed this development close enough to comment.

> * View compaction button.
> * View info view (err, view of the info about a view)

Like what info?

In response to some of the Futon feedback on this thread, let me talk  
a bit about documentation of the JS files. Futon comes with a colorful  
mix of JS files, some written by third parties (jquery.js, json2.js,  
jquery.form.js, etc) and many by myself and other CouchDB hackers.

For the former we can of course defer to the official documentation,  
which is often included in the file itself. For the latter, it'd sure  
be nice if they were documented in some way. One challenge with the  
(rapidly increasing number of) Javascript files used by Futon and the  
test suite is that Futon is just a collection of static files. In  
addition, we want to be able to "run" them directly from the source  
directory to enable easy development. That means that we can't really  
have extensively commented Javascript files if we still want Futon to  
load somewhat quickly.

Ideally, the JS source files would be extensively commented, but then  
minified during the installation process (for example using the yui  
compressor, if enabled and installed). I don't know if we could get  
that to work, or how hard it would be. Certainly would be nice. We  
could also compress jquery/json2/etc in that case, which are currently  
included in their uncompressed form (which is uncomfortably large).  
Maybe we could even concat a couple of the scripts to reduce the  
number of requests needed in Futon.

Alternatively, we could document the JS files out-of-band, such as on  
a set of Wiki pages, or in text files in the repository. But the very  
real risk here is that the docs will quickly get out of date as people  
change the code but forget to update the docs.


Christopher Lenz
   cmlenz at

View raw message