- From: Joern Turner <joern.turner@betterform.de>
- Date: Tue, 03 Apr 2012 21:46:25 +0200
- To: Alain Couthures <alain.couthures@agencexml.com>
- CC: public-xformsusers@w3.org
Hi Alan, Am 03.04.12 21:14, schrieb Alain Couthures: > Hello, > > While implementing upload control in XSLTForms > (http://www.agencexml.com/xsltforms/uploads.xml), I was wondering in > what real use cases it can be used. > > With xsi:anyURI type, the server only gets a filename (usually prefixed > by "fakedpath") for security reasons. So, only the short name (not the > full path) is meaningful. True - however in our scenario (server-side) it's no problem to de-reference this link against the root-context of the application. So it's just a standard file upload. For bigger files where the instance data store some meta-data this is the right solution. > > With xsi:hexBinary and xsi:base64Binary, the full content of the chosen > file is copied and expanded (2 times or 1.67 times respectively) within > an instance. Uploading big files will require time (and memory) and a > progress bar with a cancel option would be useful and, then, submission > will also take time... I think these two options are surely more appropriate when you want to use to store smaller pieces of data (esp. binary data) that you'd like to include directly within your instance data. We had a practical example when building a configuration frontend for a security appliance that use certificates. It was a convenient fit here to store the certs base64 encoded directly within the configuration file. Btw, our upload has a progress indicator though we do not have a cancel option yet - and due to the browser security model it's very hard to implement an effective cancel option. Joern > > So, what are the effective or expected use cases for the upload control? > > Thank you for your answers! > > -Alain > > >
Received on Tuesday, 3 April 2012 19:46:47 UTC