couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Futon Improvements
Date Thu, 10 Sep 2009 22:27:15 GMT
Chris,

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

I didn't have a specific vision when I considered this, just the
common frustration. Though running off your idea, I think something
that could be plausible might be like:

Adding new values keeps the current behavior
Editing an existing string value would do magic to json decode the
value and put it in a text box if it had newlines, or a plain text
field otherwise
Editing other types is the same

As to viewing, detect if the value is a string and 'make it pretty' is
about all I can come up with. Using a <pre> around it to preserve the
new lines, maybe trimming to the first N characters or similar.

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

Touché. Reporting errors encountered during the view build would also
improve the experience for all users of the view.

Thoughts that come to mind would be to add a "status": ("error" |
"ok") to view output and then a secondary endpoint that you could use
to retrieve the actual error. Candidates for info might be the number
and types of errors, first docid where those errors occurred, etc etc.
I don't think I'd want to keep all the tracebacks for errors, maybe
one for each type or something.

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

I must admit that my real motivation is to delete all of the
_temp_view code. I understand the desire to provide a quick
learning/dev/testing tool I just wish we could find a decent way to
provide that without _temp_views. This was just one of the more
reasonable ways to remove the _temp_view dependence. The other one
that I remember was to have _temp_view create a _design/$(UUID)
document that had a '"futon": true' member which would allow for a
button that said "Delete Temporary Design Docs". Now that we have
index files by hash, this would also allow for "Done developing, save
as real view" and there'd be no need to recalculate.

>> * Frickin tab support in the function editing boxes.
>
> Would that insert tabs or spaces? And what indentation level should be used?
> :P J/K
>

7 apostrophes would be fine as long as focus doesn't leave the text
area I'm looking at. :)

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

I was thinking that we either just use well known names and delete
those or register the databases. Technically registering would be
cleaner, but tagging the db and then iterating an unbounded number of
db's seems like it could get weird.

>> * 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 ;)

I was thinking a drop down next to run with values of
True/False/Level. When Level is selected, dynamically show a small
text field that accepts only integers.

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

A URL like:
http://127.0.0.1:5984/test_suite_db/_design/test2/_info

Gives:
{
  "name":"test2",
  "view_index":{
    "signature":"f740096892b522e24d9088cab46e0860",
    "language":"javascript",
    "disk_size":4185,
    "compact_running":false
  }
}

> 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?

My vote is for inline docs that get removed during a compression step
in the build process. OOB docs are always out of date, and incorrect
docs are worse than no docs as they say.

> Cheers,
> --
> Christopher Lenz
>  cmlenz at gmx.de
>  http://www.cmlenz.net/
>
>

Paul Davis

Mime
View raw message