Re: advice? new file upload API and mime content-type
Re: advice? new file upload API and mime content-type
- Subject: Re: advice? new file upload API and mime content-type
- From: Hsu <email@hidden>
- Date: Tue, 11 Feb 2003 20:07:51 -0800
I'm pretty sure that the mimeType binding on WOFileUpload will do what
you want, but I figured I'd answer some questions anyway.
Previous to 5.2, I just parsed the WORequest myself to get the
content-type for the uploaded file. It's in the content(), not in the
WORequest headers, because it's not a header for the whole request,
just for one of the parts of the multipart request. But now, I don't
want to have the whole WORequest in memory at once since I don't have
to, I don't think. And in fact, if I use the streaming API, I'm not
sure if I _can_ access the WORequest content() itself.
Well, you are allowed to call WORequest.formValues(), and you should
get something interesting. formValues() will parse until the first
unprocessed file upload - and it parses the headers for that fileupload
as well (and presents them in a very strange format I think - something
like form-data-name.header-name=value). (Once a file upload has been
processed, the formValue parsing will continue until the ntext
unprocessed fileupload. Yes, this means that repeated calls to
formValues() may return a different result each time).
The WOFileUpload dynamic element doesn't provide any bindings to
expose this mime content-type. The WOMultipartFileIterator/WOFormData
API does expose this information, but the documentation tells you not
to use this API with the WOFileUpload in a component-action request.
Generally, that's true. The WOFileUpload DE uses the iterator to do
it's work - mussing with the iterator could have interesting
consequences.
2) Even though it's in a component-action based application, make my
file upload request be to a direct action URL.
This probably isn't a great way to think about an application -
applications aren't intended to be "Direct Action Based" or "Component
Based". It should be easy to mix the two as you feel is necessary to
get the results you want.
To make things seemless in a component-action app, I'd probably store
something in the Session, something like
"componentToReturnAfterUploadProcess" would be a component
instance---the direct action would handle the upload, do what it needs
to do with the content-type using the WOMultipartFileIterator
interface, and then grab the component instance out of the WOSession
and return it, to return to ordinary component-action-based flow.
Questions: Is this a bad idea somehow? Will it cause problems for me?
This is perfectly fine. You don't have to do anything complicated - at
the end of your action, just do
return pageWithName("SomePage");
3) Even though I'm using the new streaming API, access the
WORequest.content() in full anyway, parse it for the content-type.
Question: Is there a way to do this that doens't completely defeat the
purpose of the streaming upload?
There is a way - write a replacement for the WOMultipartIterator :)
Karl
--
You can't be late until you show up.
Homepage:
http://homepage.mac.com/khsu/index.html
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.