RE: Possible bug with file upload control inside repe at

> This is using xforms NG, with a nightly build from about 3 weeks ago.
>
> The problem seems to be when the conversion from xforms-xhtml to regular
> html takes place.
>
> If there are no file upload controls that need to be displayed on the
> form when it first loads, then the <form/> element in the generated html
> doesn't have an 'enctype' at all which is what you'd expect. So when you
> submit the form you'd get a standard HttpServletRequest.
>
> E.g:
> <form id="xforms-form" class="xforms-form"
> action="/oip-forms-viewer/xforms-server-submit" method="POST"
> onsubmit="return false">
>
> If there are file upload controls present then the <form/> element has
> enctype='multipart/form-data' which means when you submit your
> HttpServletRequest will being of a somewhat different format to cater
> for the fact that there is file upload data coming through as well.
>
> E.g:
> <form id="xforms-form" class="xforms-form"
> action="/oip-forms-viewer/xforms-server-submit" method="POST"
> onsubmit="return false" enctype="multipart/form-data">
>
> But there is actually a third case where the file upload controls are
> within a repeat and none need to be displayed when the form first loads
> but you can add a row to the repeat which will display a file upload
> control, unfortunatelly when you add a row to the repeat the <form/>
> element doesn't get regenerated so when you try to submit the form the
> HttpServletRequest is still in it's original format so no processing of
> upload data gets done, essentially file uploads are ignored.
>
> It's a little hard to create a reproducible case for this as you need to
> save the instance to see that the file data wasn't processed. In the
> case of our application the submitted instance eventually makes it's way
> into a custom processor that we wrote. We expect the file data to be a
> base64 string by the time the instance gets to the custom processor
> which normally it is unless what I described above happens, in which
> case all we get is a filename (i.e. the file upload data wasn't processed).
>
> Hopefully this is enough info to go on.
>
> I'll try and create a reproducible example some time today if I get the
> time.
>
> -----Original Message-----
> From: Erik Bruchez [mailto:[hidden email]]
> Sent: Monday, May 15, 2006 10:31 PM
> To: [hidden email]
> Subject: Re: [ops-users] Possible bug with file upload control inside
> repeat
>
> Alan,
>
> Is this with XForms Classic or NG?
>
> Can you send a small reproducible case?
>
> -Erik
>
> Alan Skorkin wrote:
>  > Hi,
>  >
>  > We've encountered a possible bug when using file upload controls
>  > inside repeats.
>  >
>  > The scenario is the following:
>  >
>  >  - you have a repeat which contains a file upload control in it
>  >  - you put the repeat on the form
>  >  - the repeat initially contains no rows (there is an insert button to
>  > insert rows)
>  >  - you press the insert button which insert a row in the repeat, the
>  > row has a file upload
>  >  - you may now browse to a file you want to upload
>  >
>  > Unfortunately if you now try to submit the form the
>  > enctype='multipart/form-data' which should be present on the 'form'
>  >
>  > element in the html (if you view source), is not there. Therefore the
>  > files can't get uploaded properly.
>  >
>  > We are using type="xs:base64Binary" for our files so we expect a
>  > base64 string when we submit, but since the submission encoding is not
>  > 'multipart/form-data' the uploaded file doesn't get read at all.
>  >
>  > If the repeat, initially when the form first loads has at least one
>  > visible row with a file upload, or if there are other file upload
>  > controls
>  >
>  > on the form then the enctype='multipart/form-data' is present and
>  > there is no problem.
>  >
>  > I believe this is a bug with file uploads inside repeats.
>  >
>  > Cheers,
>  >
>  > Alan
>  >
>  > ---------------------------------------------------------------------_
>  > _
>  > _Alan Skorkin_
>  > Consultant
>  > Object Consulting
>  >
>  > [hidden email]
>  > ___www.objectconsulting.com.au_
>  >
>  > consulting | development | training | support Our Experience Makes The
>  > Difference
>  > ---------------------------------------------------------------------
>  >
>  >
>  > ----------------------------------------------------------------------
>  > --
>  >
>  >
>  > --
>  > You receive this message as a subscriber of the
> [hidden email] mailing list.
>  > To unsubscribe: mailto:[hidden email]
>  > For general help: mailto:[hidden email]?subject=help
>  > ObjectWeb mailing lists service home page:
>  > http://www.objectweb.org/wws
>
>
> --
> Orbeon - XForms Everywhere:
> http://www.orbeon.com/blog/
>
>
> ------------------------------------------------------------------------
>
>
> --
> You receive this message as a subscriber of the [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws