For example, if you placed an xforms:input field into a grid cell, Form Builder would enable its xforms:input alternative, and disable all the other controls (xforms:select, xforms:textarea, etc.) in the cell.
This approach has a number of issues:
- Each control type you want to support in a WYSIWYG way has to be known by Form Builder in advance.
- Form Builder becomes more complex as more control types need to be supported and simulated. This is particularly hard for XBL controls.
- The size of the Form Builder HTML increases greatly with each new control you add.
So there is a tradeoff between keeping Form Builder simple and efficient, and supporting more control types, including XBL controls.
For the next version of Form Builder, which will support a host of new features such as repeats, tab views, and nested sections, we figured that this approach had to be revised, and we realized that we should just let the XForms engine interpret the form as it is being created in Form Builder!
This simplifies the architecture of Form Builder greatly and allows it to support any XBL control without extra work, as well as facilitating the support of repeats and other features.
So yesterday we have committed changes to XForms engine that we have been working on for quite some time. These changes allow the XForms engine to dynamically evaluate and update a sub-form, via an extension called xxforms:dynamic.
The next version of Form Builder, under development, uses xxforms:dynamic to point to an XForms instance containing the form being edited. As the user builds the form through Form Builder, the XForms engine automatically reflects the changes. Form Builder itself can just relax!