XForms-Transitional Testbed - repeating fieldsets

This is part of a series of cross-platform experiments in incremental extensions to HTML4 forms that provide a stepping stone towards the much richer capabilities in XForms. This particular experiment introduces a repeat-number attribute which can be used with the fieldset element to indicate when the enclosed fields can be repeated. The Value of the attribute is number of "rows" shown to start with, and must be an integer greater or equal to 1 if the fields are to be repeatable. If the repeat attribute is missing, the content of the fieldset element will be left unchanged, rather than being rewritten as a table. Field initialization is examined in further experiments.

Try entering some numbers for the number purchased and the prices per unit and the total price should be updated as the focus leaves the changed field. Please view the XForms-Transitional script for more details on how this works.

Here is the markup for the above form:

<form name="form1">
<fieldset name="lineItem" repeat-number="4">
<legend>Repeating groups of fields</legend>
<label for="item">Product Name</label>
<label for="quantity">Number Purchased</label>
<label for="unitprice">Price Per Unit</label>
<input name="item" datatype="text" title="product name"/>
<input name="quantity" datatype="number" title="number purchased"/>
<input name="unitprice" datatype="number" title="price per unit"/>
</fieldset>

<p><label for="total">Total price</label>
<input name="total" readonly="readonly"
 calculate="sumover(lineItem, quantity*unitprice)"/>
<button type="submit">Submit</button>
<button type="reset">Reset</button></p>
</form>

Comments

The library expects a set of fields and matching labels. This is transformed into a table with the number of rows taken from the repeat-number attribute on the fieldset element. This ensures that the labels are aligned with the corresponding columns. Note that there must be a label for each field in the template. A name attribute may be given with the fieldset for use in mapping the form data into an XML data model.

This works through a mechanism for rewriting expressions so that they can be computed with the JavaScript eval function. It should be straightforward to write a simple parser to ensure that the expression satisfies the constraints, but static analysis of cross field dependencies is impractical for external function calls, so these should avoid introducing such dependencies. A simple solution is to restrict expressions to a predefined set of functions with well defined semantics.

The library currently only supports a fixed number of rows, but in principle, there could be methods to append a new row and to delete an existing row. This assumes a user interface for invoking these functions. It might be simpler to automatically add a new row when the last row is filled out. One idea is to suport button elements with type="add" (or "delete", etc.) together with name and value attributes. On older browsers with scripting disabled, pressing the button would have the effect of submitting the form, allowing the server to add or delete the row, based upon the name/value pair for the button that was pressed.

A related issue is how to initialize the data after a "back" or "reload" operation. This isn't a problem if the data is included in the page's markup, and only occurs when the fields are generated automatically. Ideally, there would be a way for web page scripts to access the history state for the current page as this would allow the script to restore the state for dynamically generated markup.

Dave Raggett <dsr@w3.org>