Using subforms in XForms

Over they years I've had cause to write many different kinds of form-based applications. At one time I had to write them in C++ or Java, but that was a long time ago! For simple applications that had to be produced quickly (and could change a lot) I had to use VB or Microsoft Access. But like most people nowadays, most of the recent decade has been spent using one kind of server-based application after another to produce HTML user interfaces.

But no matter which language was used, the same problem always presented itself; how do we make big forms out of small forms?

We've been working on this a lot lately, because some of the forms in a current project are very big. Of course, they could be made smaller, and we could get our users to move from one form to another as they perform their tasks. But doing this would require us to pass state information between forms, either in cookies on the client, or via the server, and the latter approach binds us in far too tightly to the server software. (See skimming.)

The ideal technique is of course to only load parts of the form as they are needed. But this is not as easy as it sounds, and keeping track of this at design and build time, especially in a scripted environment, is next to impossible.

In all the years I've been building applications, I've never managed to find a decent solution, but I feel that XForms may finally provide a reasonable way.

Extending the load action

The technique we used on the current project is to extend the XForms load action to include:

• a target attribute to indicate where to place the sub-form;
• an additional value in the show attribute of embed.

To show how it works, here is an example of how we place a sub-form into a case when the user toggles that case:

<xf:load
 target="div-work-list-choose"
 ev:observer="case-work-list-choose" ev:event="xforms-select"
 show="embed" resource="subforms/sf-work-list.xml"
/>

We use the term sub-form to describe the document that is loaded because it may have more than just controls; it may include its own models, submissions, bind statements, and so on.

Using XLink

The extensions to load are of course non-standard, and this is still very experimental. But it is worth saying that there is logic behind the way we've done this. For a start, XForms really should support a target attribute on the load action anyway, which would allow new documents to be loaded into frames or other locations.

But also, the show attribute in XForms is actually modelled on the XLink show attribute, and the currently supported values--replace and new--come from that...as does embed. In other words, all we're suggesting here is that XForms supports a little bit more of XLink.

As it happens, our first version of this functionality achieved it using raw XLink, but the problem is that XLink says nothing about when to load the sub-form. Once we started looking at attaching event listeners, we quickly came to the conclusion that load was much more appropriate, particularly because it already made use of XLink.

Conclusion

However we do this in the future, and whatever mark-up is used, XForms definitely provides the hooks for a flexible way to build complex forms on the fly. Defining the loading of sub-forms using declarative mark-up makes it intuitive for authors to use this feature, and makes the management of the components much easier.

---

Tags: webapps | programming | web standards | standards | browser | CDF | Compound Documents | XML | HTML | XHTML | XHTML 2 | W3C | XForms | XInclude | XForms