On Tue, Apr 21, 2009 at 11:44 AM, Dean Landolt <[email protected]> wrote: > On Mon, Apr 20, 2009 at 11:54 PM, Curt Arnold <[email protected]> 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@ >>> >>> Cheers >>> Jan >>> -- >>> >>> >> >> 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 >> blunders. >> >> Feature: End point for HTML form submissions for file uploading >> Use case: Uploading files from browser when their is not intermediate >> layer. >> >> Info that must be encoded somewhere: >> >> database URL >> docID >> 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 >> >> Considerations: >> >> 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?
This is the way to go. Not action servers exactly, but an update handler, for JavaScript which can translate a Req to JSON for PUT. Patches welcome or I'll get to it eventually. >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 > sharding. > > 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? > -- Chris Anderson http://jchrisa.net http://couch.io
