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
testing.
* 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.
Thoughts?
Cheers,
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
