One area where a novice form designer often needs help is in figuring out how to bind their form to data. Ok, scratch that. Advanced form designers often need help in this area as well. There is lots of reading you can do in the XFA specification to learn how the template DOM gets merged with the data DOM to produce the form DOM. Designer does a great job of generating binding SOM expressions for you. But even still, when you are dealing with a complex schema, it can be hard to figure out where things went wrong.
A good way to debug this problem is to visualize the resulting DOMs. Since we have full scripting access to the form DOM and to the data DOM, we can add a visual display of the DOMs to our form. That’s the approach that today’s sample takes. I took a work-in-progress purchase order form and added a "debugging subform" (domDump) at the end of the form in order to display the DOMs. When you open the form and look at the last page you will see two side-by-side subforms. The left side shows a tree view of the form DOM, the right side shows a tree view of the data DOM. Some of the things you should note:
- Entries in the tree are color-coded depending on their bind status
- The display is cut off at one page. To see more, use the scroll buttons at the top
- Collapse and expand sections of the trees using the +/- buttons on the rows
- Set focus in a field on either side of the tree and the display will highlight that entry and the corresponding entry(s) in the other DOM in red.
- Set focus on a row in the form DOM, and some binding information is displayed in the top right of the display
- Shift+click on a row in the form DOM will set focus to the corresponding field on the form.
- By default we display the current state of the form at the docReady event. If you want to refresh/rebuild the tree views, click the refresh button.
To try this out on your own forms, take the domDump subform and add it to your object library in Designer. When you want to debug a form, drag the domDump subform onto your form. (The subform needs to be displayed on a new master page with a content area that is at least 8×10.5 inches.) After debugging, when you are happy with your form, remove domDump.
There are some restrictions on the usage of this tool:
It works only on interactive forms
- It works only on dynamic forms
There is code in the script to check that these conditions have been met.
For interest sake, I’ve included one of my previous samples with the debugging subform added. When I first added the dompDump subform I had to press the "refresh" button in order to see the completed DOMs. That’s because the transpromo content and the debugging content are both populated from the docReady event — and the transpromo happens last.
- Admittedly, displaying tree views using dynamic subforms is non-trivial and a bit clunky. One possible enhancement would be that rather than display the tree view on the form, we could export all the data for the tree views. Then we could write a cool flash app to load the data give a proper rich user experience. The only drawbacks with that approach is that a) it becomes a multi-step process and b) you lose the ability to "shift+click" to the corresponding form field.
- It would be great to have a similar debugging capability for WSDL connections.
March 19 Update
After using the form DOM debugger with several forms, I’m hooked. I couldn’t resist making a couple improvements to it. I’ve lifted most of the restrictions as to what flavour of forms it can be used in. It now works with a broader range of template versions and strict scoping variations. It also works for non-interactive documents. For non-interactive, the tree display will spill over multiple pages and give a full dump — rather than windowing the content on a single page. The only remaining restriction is that it works only with dynamic forms.
There is a follow-up debugger effort that supercedes the sample in this entry. Please have a look here.