XForms/Saving Intermediate Form Data

NOTE - this page is in development

Saving Intermediate Form Data

This example will show you how to save intermediate form data to a local disk.

Motivation

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

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

Step 1: Save to Client

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

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 xf:submissions save-instance-to-file and read-instance-from-file should be a variable: action="file://C:/tmp/xforms/my-data.xml" should be automatically changed to FilePath value.

Solution

To get this to work you have to deal with the security concerns...

Notes

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://

References

• [1] Cross Domain Submission
• [2] Comments from Mark Bireck