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:02:12 -0800
WOFileUpload has a mimeType binding - look at the FileUpload example
for usage (though really, it's just "mimeType" bound to a String).
Strange that it's not in the DE reference. You should file a bug.
Karl
On Tuesday, February 11, 2003, at 01:09 PM, Jonathan Rochkind wrote:
So I'm excited about the new file upload API. The problem is that I
need access to the browser-supplied mime content-type for the uploaded
file too.
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.
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.
So here are the options I can think of. I'd appreciate any advice for
which seems best to procede with. Or maybe there's one I missed.
1) Don't use WOFileUpload. Write my own dynamic element that provides
the HTML input type=file tag, and handles the upload, and would access
the WOMultipartFileIterator API to provide a content-type binding.
Questions: How hard would this be? Why does the existing WOFileUpload
not compatible with WOMultipartFileIterator API in a component-action
request, and will I run into the same issue?
2) Even though it's in a component-action based application, make my
file upload request be to a direct action URL. 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?
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? Probably not---even if I can keep
the content() from staying in memory (in two copies!) after I'm done
parsing it (which I'm not sure I can do), if the upload is
exceptionally large, even having it memory once temporarily may
produce Java out of memory exceptions. So I think I can rule this out.
Any other ideas I'm not thinking of? Any advice?
--Jonathan
_______________________________________________
WebObjects-dev mailing list
email@hidden
http://www.omnigroup.com/mailman/listinfo/webobjects-dev
--
Really get stoned, drink wet cement.
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.