XForms/Saving Intermediate Form Data
NOTE - this page is in development[edit | edit source]
Saving Intermediate Form Data[edit | edit source]
This example will show you how to save intermediate form data to a local disk.
Motivation[edit | edit source]
Sometimes long forms take a while to fill out. You would like to allow users to fill out part of a form, log off, and resume their form when they return. Sometimes this intermediate data can be used as a default template for fields that are re-entered frequently by form users.
Cross Domain Posting A Security Concern[edit | edit source]
By default, XForms will not allow a form to be served from one domain and then access another domain without the user being warned. This could allow a nefarious form to access local files without authorization.
This is reflected in the fact that the "src" tag in the instance can only reference a hard-coded static string. You can not load a local file into an instance if the form was loaded from a web server.
Note that you can read and write a local file on the local file system with an XForms application that supports the file: type such as FireFox. But the forms must have this path statically coded into the XForms instance src attribute.
Steps[edit | edit source]
Step 1: Save to Client[edit | edit source]
Save instance data:
<xf:submission id="save-instance-to-client" method="put" action="file://C:/tmp/xforms/my-data.xml" replace="instance" instance="my-instance" />
Step 2: Read From Client[edit | edit source]
Save instance data:
<xf:submission id="read-instance-from-client" method="get" action="file://C:/tmp/xforms/my-data.xml" replace="instance" instance="my-instance" />
Note that to find the file you can use the <xf:upload> control:
<xf:upload ref="FilePath"> <xf:mediatype>text/xml</xf:mediatype> </xf:upload>
The value of the
action attribute in both
read-instance-from-file should be a variable:
action="file://C:/tmp/xforms/my-data.xml" should be automatically changed to
Solution[edit | edit source]
To get this to work you have to deal with the security concerns...
Notes[edit | edit source]
There was a reference to using the chrome:// prefix not the file:// prefix on one posting..but no example was given. There was also some discussion of saving to a cookie using cookie://