One of our customers recently asked:

"I have a question on how we can open an XForms page from a non-XForms page. We are trying to have a summary page which is a non-XForm page and we would like to try to open an already existing XForms page by populating data on to it dynamically, by clicking on a component in the summary page. More like a summary-to-detail functionality....

We are trying to find the best way to do this."

It's an interesting question, and although we have worked out a couple of ways of looking at this on the client side, I thought the best answer for now was to user the server.

The easiest way to do this is for the page being linked from to pass whatever parameters are needed in the URL, and for a server-side process to make use of those values when preparing the XForm.

For example, the user might click on a link like this:

ht<!-- -->tp://mysite.com/newform.xyz?name=Mark

Where xyz is whatever server-side processor you happen to be using, such as ASP,
PHP, JSP, etc.

The server-side script would then create a form as usual, but place the parameters that were passed in to it, into the instance data. Depending on the language, it would look something like this:

<xf:instance xmlns="">
  <data>
    <name><% =Query("name") %></name>
  </data>
</xf:instance>

When the form reaches formsPlayer or Ubiquity XForms, it will just look like a normal form, with inline instance data -- the fact that it was generated on the server will be irrelevant.

Decoupling

An extension of this technique is to decouple the data from the form by 'bouncing' the parameter on from the form, to a subsequent request for data.

This is achieved by altering newform.xyz so that the parameter is used in the @src attribute on xf:instance, like this:

<xf:instance src="getdata.xyz?name=<% =Query("name") %>" />

The effect here is that when the form is loaded, a second request is immediately made to your server for the instance data, and the URL for that instance data will include the name parameter that was passed to the form generation script. getdata.xyz obviously needs to be a script too, but this time it only needs to worry about creating XML, and not the rest of the form. It might look something like this:

<data xmlns="">
  <name><% =Query("name") %></name>
</data>

Centralising data management

This technique could be taken further and in the getdata.xyz script a query for data could be run, based on the parameter -- or parameters -- passed in. So the original link that the user clicks might look like this:

ht<!-- -->tp://mysite.com/customer.xyz?id=72

The customer.xyz form might generate a 'bounce' to the data that looks like this:

<xf:instance src="getdata.xyz?type=customer&amp;id=<% =Query("id") %>" />

Now getdata.xyz could use type to determine which tables to query, and id to decide which item to retrieve; which means that all data requests could be passed through this one script.

REST and APIs

Now, one final step is to tidy up our URLs a bit, so that the script name is irrelevant, and the data structure comes to the fore. The link that the user clicks on might look like this:

ht<!-- -->tp://mysite.com/customer/72

and the instance data request generated in the form might look like this:

<xf:instance src="customer/<% =Query("id") %>.xml" />

For example:

ht<!-- -->tp://mysite.com/customer/72.xml

This is starting to look a lot like putting XForms on top of a RESTful API.

And if we threw in an XQuery database like eXist, we could dispense with having to manage any server-side scripts at all!