Page 280 -

276 M. Adams

Fig. 10.6 The resultant dynamic form (derived from Listing 10.2)

inputs. In addition, mandatory fields (i.e., those that require a value to be entered)
are shown with a yellow background,while optional fields have a white background,
and every field has a mouse-over tool-tip that displays a prompt about the type of
data expected.
When a user attempts to save a dynamic form, each user-provided value is vali-
dated against its data type, along with any further restrictions specified in its schema.
Fields with invalid values change to a red background, and an appropriate error
message is also displayed; the form cannot be saved until all fields validate.
Referring again to Listing 10.2 and Fig. 10.6, the definition of a complex type in
the schema results in the creation of a form panel, within which its child fields are
contained. Such definitions that have a maxOccurs value greater than its minOccurs
value (if omitted, the default values for these attributes is 1), or is “unbounded,”
will also be rendered with small increase and decrease buttons in the top right of
their sub-panel. These buttons allow multiple sets of those fields to be dynamically
created or removed by the user. In the example, an order may have any number of
lines (one for each item ordered) and any number of packages; a user can easily
increase or decrease the number of order lines or packages as appropriate for each
order.
Dynamic forms are designed for maximum flexibility and can display work item
parameters of any data type. However, their generic look and feel may not be appro-
priate in all cases, for example where an organization has a standardized set of
forms for their business processes, and would like their web-based forms to match