Yes, it’s a limitation. So try the ajax widget instead :-) See how that works out for you.
> On Jul 13, 2025, at 4:39 PM, OCsite <o...@ocs.cz> wrote: > > Aaron, > > well, your vague remembrance brought me to the very thing I should have done > at first, that is, digging up and checking the legacy WebObjects > documentation. For it simply and unequivocally states > > === > inputStream > > WebObjects sets this attribute to an InputStream representing the contents of > the file upload. This binding > can be used only when it is the only WOFileUpload element on the page. > === > > D'oh. > > Thanks a lot, > OC > >> On 13. 7. 2025, at 16:26, Aaron Rosenzweig <aa...@chatnbike.com> wrote: >> >> Hi OC, >> >> I vaguely remember that if there is a streaming upload it needs to be last >> in the form (vertically top-down). Anything after it won’t get synchronized >> to the bound variables. >> >> I also remember something about a legacy multipart parser that might help >> you do what you want but I couldn’t find it just now when I looked. >> >> Perhaps you can try an “AjaxFlexibleFileUpload” and let the users stream at >> that moment instead of after clicking send at the bottom of the page. >> Sometimes we you hit a brick wall, you need to walk around. >> >>> On Jul 12, 2025, at 9:23 AM, OCsite via Webobjects-dev >>> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> >>> wrote: >>> >>> Hi there, >>> >>> I've just bumped into something weird. I often use uploads to memory, like >>> this: >>> >>> === >>> <wo:form enctype="multipart/form-data"> >>> <wo:fileUpload data="$fileData" filePath="$fileName" >>> mimeType="$mime"/> >>> <wo:submit value="Import" action="$import"/> >>> </wo> >>> === >>> >>> they work without problems, and there can be any number of them in the same >>> page. But now I've added an upload to file, like this: >>> >>> === >>> <wo:form enctype="multipart/form-data"> >>> <wo:fileUpload finalFilePath="$fileName" >>> streamToFilePath="$filePath" filePath="$originalFilePath" mimeType="$mime"/> >>> <wo:submit value="Upload" action="$upload"/> >>> </wo> >>> === >>> >>> and it seems whenever it is in page, no other upload (of any type) can be >>> there. Testing seems to suggest that >>> - as already mentioned, any number of to-memory uploads in a page works all >>> right, presumed there's no to-file one in there >>> - if there's a single to-file upload in a page and any number of to-memory >>> ones, the to-file one works, but all the to-memory ones fail >>> - if there's more to-file uploads in a page, all the uploads (of any type) >>> fail. >>> >>> The failure looks like this: >>> >>> === >>> Caused by: java.lang.IllegalStateException: >>> <com.webobjects.appserver._private.WOFileUpload> No form data left for >>> WOFileUpload! >>> at - WOFileUpload.takeValuesFromRequest(WOFileUpload.java:247) >>> at - >>> WODynamicGroup.takeChildrenValuesFromRequest(WODynamicGroup.java:84) >>> ... >>> === >>> >>> Does this make any sense? Can it be fixed or worked around anyhow, so that >>> all uploads in a page which contains (at least) one to-file upload work? >>> >>> Thanks a lot! >>> OC >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >>> <mailto:Webobjects-dev@lists.apple.com>) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com >>> >>> <https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com> >>> >>> This email sent to aa...@chatnbike.com >> >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
