On Mon, Apr 20, 2009 at 11:54 PM, Curt Arnold wrote:
On Apr 19, 2009, at 7:01 AM, Jan Lehnardt wrote:

On 19 Apr 2009, at 05:16, Oliver Boermans wrote:

Excellent summary, thanks! We're open to enable the API handlers for
pure HTML forms with more features, if you can line out what you would
want to have.

Moving to dev@

I haven't had the time I would like to research this adequately. I thought
it would good to keep the discussion going, so please forgive any obvious

Feature: End point for HTML form submissions for file uploading
Use case: Uploading files from browser when their is not intermediate

Info that must be encoded somewhere:

database URL
rev (for modifications)
content type of attachment
content of attachment
attachment name

Possible locations:

database URL: That has to go in the action URL for the form
Content of attachment: In body of POST request per HTML spec
docID: Could be encoded in either the action URL, content of a field
(possibly hidden), or field name.
rev: Same options
Content type: The POST request will have a content-type from the browser in
the header for the file content, however the form author may want to allow
the user to explicitly specify a content type.
Attachment name: Name of input type="file" field, names of files selected,
content of hidden field


Should we provide a mechanism to change the body of the document
simultaneously. For example, if there is a field "body", it would be
interpreted as JSON and replace the current document contents.

A file input control can select and upload multiple files. If attachment
name is based on the field name, likely would need to add an index to
support the case when there are multiple files selected.

The local file names may be missing from the post body, might not be unique
and might be approximations. I'd avoid basing the attachment name off of
them, thought it would be good if they could be preserved. Any chance that
they could be added to the _attachments metadata?

My current though is something like:

Action URL: http//server:5984/database/_form?multi=true|false

Special field names for docID, rev and body

If multi=true, multiple selections of files would be supported and
attachments would be named from the field name + [index]
If multi=false, if multiple files were selected, the request would be
rejected. Otherwise attachment would be named after the input field
For every file input control, if there is another field with that name +
"content-type", the value of that field would be used for the content type.
Otherwise, the content type provided by the browser would be used.

Ideally, the local names of the uploaded files would be preserved in the
metadata for the attachment.
This seems like an awful lot of special case weirdness, and there are
probably more edge cases than you've identified so far. And this only
addresses attachments -- there were some interesting ideas posed on the list
some time back about how to do unobtrusive form handling, but there were
still were some oddities, particularly around strings vs. numbers and
deeply-nested objects.

I know this is sacrilege, but wouldn't this be best handled by action
servers? Of course, you could always bury a form handler in a wsgi or rack
app or whatever (even a jack app in js) as an _external, but obviously
that's not very portable. Baking action servers into couch is the only sane
way to solve this problem for something like couchapps (a jsonp service is
out of the question for write ops). And it shouldn't be any trouble with

So maybe action server is the wrong word, and I know it could totally get
abused (hell, I *know *I would abuse it), but wouldn't it be great if form
handling could be embedded in design docs with all the other app logic?

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 3 of 6 | next ›
Discussion Overview
groupdev @
postedApr 19, '09 at 12:02p
activeMay 3, '09 at 8:16p



site design / logo © 2018 Grokbase