advice? new file upload API and mime content-type
advice? new file upload API and mime content-type
- Subject: advice? new file upload API and mime content-type
- From: Jonathan Rochkind <email@hidden>
- Date: Tue, 11 Feb 2003 15:09:31 -0600
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
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.