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.132.240 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type;
        b=KG2c0V1pSK0zd+h86dbjRYm4qOxR6x9zr6hHvH3iUDd8vxwoxYx5P+x4WqtOXHxWRc
         b1bAIa6OtGpyDMZwUInWFWzr13EJtGl9lWCQRskhgMvx7rvnUPNRnUrZPxGt9uzRX/r7
         ncjarsC5hsjTO5L4n8Zohv50wiRq6toZ9DalE=
MIME-Version: 1.0
Date: Wed, 9 Sep 2009 16:20:28 -0400
Message-ID: <e2111bbb0909091320v33fb31beucad40ffd5aafb170@mail.gmail.com>
Subject: Futon Improvements
From: Paul Davis <paul.joseph.davis@gmail.com>
To: dev@couchdb.apache.org, user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1

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.