© 2005 Goetz HellerTable of Contents Copyright Note back
File uploads deserve special consideration since the value of an HTML <INPUT> element of type "file" cannot be set programmatically. Therefore, it is not possible to create such an element inside the data port. What could be done is to insert a copy of an existing input element from a different form which is achieved simply by copying the corresponding DOM node into the data port. However, it turns out that Microsoft Internet Explorer does not support the DOM method importNode() which currently is the only way to get a copy of a file upload input element together with its content into the data ports document.
This being said we should lean back for a moment and think about if this is the right way doing things. Actually, I say yes - by exception of just this case. Why do we need a client server exchange under the cover when there is no need at all to hide the action from the user? What should happen to the original input element from which we wanted to take a copy? Isn't it a much better way to wrap such elements into an iframe element on its own which is visible and whose contents can be posted separately to the server, without any need to replace the surrounding client application frame? For example, this iframe might be updated on success with the list of all the files uploaded so far in this context, and contain an empty file upload element to allow the user for another file upload, while on error the server could place an appropriate message to the user inside this iframe.
To restate it clearly: Uploading files is a kind of client-server communication for which the Data Port framework is not designed.