Listing all fields in a form

Because the XDP file that defines a Designer form is just a XML file we can run an XSLT over it.

In this case we will produce a list of all the field objects that we can view in Microsoft Excel,  so we will also use Excel to run the XSLT.

First download the XSLT file, XSPFieldList.xslt , and place it in the same directory as the XDP file of your form.

Edit your form XDP file using Notepad or similar and add the following line after the XML declaration;

<?xml-stylesheet type="text/xsl" href="XDPFieldList.xslt"?>

So it should look something like;

There is a line in the XSPFieldList.xslt that looks like;

xmlns:xfa="http://www.xfa.org/schema/xfa-template/2.8/"

This might need to change to match the namespace in your XDP file (see the last line in the screen shot above)  depending on which version of Reader your form is targeting. The namespace ending in  xfa-template/2.8 means my form is targeting Reader 9.0 and above. For Reader 9.1 and above it would be xfa-template/3.0.

Now in Microsoft Excel open the XDP file (Excel doesn't know about XDP files so your will have to select "All Files (*.*)" in the Open dialog).  The first thing Excel will do is popup an Import XML... dialog;

This means it has found our xml-stylesheet line and wants to confirm we want to run the XSLT, so select "Open the file with the following stylesheet applied (select one):"

You will then get a "different format" message, which is fair enough as the XSLT will have changed the format so select Yes;

Then you get an Open XML dialog, which defaults to "As an XML table" which is what we want to do, so select OK.

 

 

The final dialog is the no schema message.  We haven't provided a schema so Excel will create one for us.  This dialog you can turn off.

 

 

 

 

The final result will look something like;

 

There is a lot you can add to the XSLT so think of this as a starting point, and remember to remove the xml-stylesheet line from the XDP as Designer will think the form is created in a new version and not allow you to do much except look at the XML Source.

Response Files

This approach can also be helpful in working with a response file from the collection of returned forms.  If you export the responses as XML then they can be processed by an XSLT and loaded into Excel in the same way.

If your XSLT produces an HTML document containing a HTML table then Excel will still load it into a spreadsheet, but you now can specify business names for the columns not just the field names from the form, so you can now have spaces in the column names. 

The XSLT will also allow you to do some decoding, such as turning 1 and 0 into 'Yes' and 'No' or whatever formatting you want.

UPDATE

Radzmar has written a macro to make the first couple of steps easier, so you no longer need to make a temporary change to your XDP file and the macro works out the correct namespace.   More details in a later blog Listing all fields in a form - The macro.

Adobe LiveCycle Designer Tip #3 - Checking your form bindings

The Report Palette is often forgotten hidden away at the bottom of the workspace, and the Binding tab of this palette is even more forgotten.

But this tab has several options for checking the bindings of your form, these are available when you click the palette menu button in the top right corner (circled in red in the image below).

Fields with Normal Data Binding

This is the default, but a binding option I have never really used.  All my forms are bound to a schema, so this tab has always been empty for me and for years totally ignored.

Fields with Data Binding by Reference

This is the option I need as it shows the name of the form object and the data connection SOM expression.

Fields with Global Data Binding

This lists all the fields with global binding, obviously enough.  But it also has a "Check Global Binding" button.  This will check all fields with the same name have global binding checked.

Designer seems pretty good at checking this as binding changes are made so I am not sure in what scenarios this error occurs, but if you are using global binding and it's not working this would be a good place to start.  (I only got this error because I was editing the XML Source).

Fields with No Data Binding

Gives a quick check that you have bound all the fields that you need to.

Fields with Import Data Binding

These are the fields that are passed to a web service call.

Fields with Export Data Binding

Theses are fields that are bound to the result of a web service call.

Unbound Data Connection Nodes

This is the opposite of Fields with No Data Binding, gives a quick check which nodes in the data connection have not yet been bound to a form object.

Objects with Dynamic Property Binding

This lists all the dynamic property bindings made for captions, list items and error messages.

This option also lists all the bindings that are set using the setProperty element.  This element allows most other form object properties to be set similar to dynamic property binding but are not supported by the Designer user interface. 

This is particularly handy as they can only be added using the XML Source view and can easily be forgotten. So if I wanted to set the presence of a form field using a value in the data connection I could add <setProperty target="presence" ref="$.presence"/> in the XML Source, where target is the form object property and ref is the data connection reference.

You can also use setProperty to refer to values that are not in the default data connection, values you don't want to be part of the form submission, such as <setProperty target="assist.toolTip" ref="!toolTips.value"> , note the data connection reference uses the "!" character which is the same as xfa.datasets.  so toolTips is a dataset at the same level as the default data one.