5.1 Introduction

XForms element model holds the instance data along with its associated type constraints. Constraints on XML instance data can be static type constraints as expressed via XML Schema; static constraints are suitable for capturing aspects of the data that are not likely to change during user interaction. Typical examples of such constraints include data type and structural constraints. In addition to holding the instance data, the schema for that instance data, and the submission details, the XForms model can encapsulate additional properties that refine the static schema constraints.

XForms defines a small number of such model properties that can be used to express dynamic constraints. These properties, in contrast to constraints expressed via XML Schema, are dynamic and are recomputed during user interaction; their updated value is immediately reflected in the user interface. The dynamic nature of model properties is key to creating online forms that exhibit a high degree of interactivity.

Model properties are authored via element bind described in Section 5.2. We described interaction-based switching in Section 4.2; model-based switching for creating conditional interaction is enabled via boolean property relevant described in Section 5.3. Property relevant can be used to advantage in dynamically revealing or hiding portions of a complex user interface.

During user interaction, it may be useful to indicate that a certain piece of data is required in order to ensure successful completion of a task; this is enabled via boolean property required , described in Section 5.4. Properties relevant and required can be used in combination in creating sophisticated electronic work-flow applications.

As an example, the user's response to an initial set of questions can be used to determine the value of relevant on portions of the model; this automatically enables portions of the user interface that bind to the fields that are relevant . Setting property required to true on these relevant fields can in turn ensure that the user gets appropriate feedback when interacting with the associated controls.

Finally, boolean property readonly , described in Section 5.5, enables certain fields to be made temporarily read-only during user interaction. This feature can prove extremely useful in work-flow applications where users with different roles work on the same form.

Complex forms can express dynamic validity constraints that are computed from the state of the current data instance; for example, a shopping application might declare that to obtain a discount, the user must buy a specific number of items. Dynamic constraints are expressed via property constraint described in Section 5.6. In addition, XForms authors can constrain the cardinality of a given set of nodes ( e.g., the number of items in a shopping cart) by creating model properties that constrain the number of nodes in a set via property constraint .

XForms enables the automatic computation of nodes in the data instance; we saw an example of this in the shopping cart application in Figure 4.10. Model property calculate is used to achieve this functionality and is described in Section 5.8.

Finally, model property type enables XForms authors to extend schemas that cannot be modified; such external schema augmentation is enabled by property type , described in Section 5.9.

5.1.1 Model Properties and CSS Style

The purpose of the XForms user interface is to convey the state of the XForms model to the user at all times. Toward this end, the current value of model properties required , relevant , readonly , and constraint for a given node in the instance tree need to be reflected in the user interface. Thus, if a field is presently read-only , it is useful to convey this information, perhaps by styling controls bound to that field using a particular presentation style.

There are also boundary conditions where the XForms model and user interface might be out of sync, for example, when a range control specifies start and end values subset the allowable values for the underlying instance; notice that in such a case, it is possible for the instance to hold a value outside this subset. As an example, consider a specialized volume control authored using range that allows the user to adjust the volume within the interval [25, 75], where the permissible values for volume lie in the interval [0, 100]. Assume further that the user interface provides a specialized mute control authored via element trigger that sets the volume to 0. When the user activates this mute control, the volume gets set to 0; consequently, the value is now outside the interval displayed by our specialized volume control, even though it is still valid with respect to the overall application; see Figure 5.1.

Figure 5.1 Conveying that model and user interface are out of sync via styling.

 <  html   xmlns  ="http://www.w3.org/1999/xhtml">   <  head  >     <  model   xmlns  ="http://www.w3.org/2002/xforms"  id  ="sound"  schema  ="units.xsd">       <  instance  >         <  settings   xmlns  ="">           <  volume   xsi:type  ="percentage"/>       </  settings  ></  instance  >     </  model  >     <  style   type  ="text/css">       @namespace xf       url(http://www.w3.org/2002/xforms);       /* blue background       for out of range form controls */       *:out-of-range {background-color:blue; }   </  style  ></  head  >   <  body  >     <  group   xmlns  ="http://www.w3.org/2002/xforms">       <  range   ref  ="/settings/volume"  start  ="25"  end  ="75"  step  ="5">       <  label  >Adjust Volume</  label  ></  range  >       <  trigger   ev:event  ="DOMActivate">         <  label  >Mute</  label  >         <  action  >           <  setvalue   ref  ="/settings/volume">           0</  setvalue  >       <  message  >Muted</  message  ></  action  ></  trigger  > </  group  ></  body  ></  html  > 

XForms uses a relatively advanced CSS feature called pseudoclasses to enable the styling of form controls to reflect the state of the underlying data. We have seen the use of attribute class in many of the user interface examples in this book when creating CSS style rules to apply to a set of controls. CSS pseudoclasses can be thought of as creating an imaginary class attribute on elements, based on the state of the underlying document tree.

Consider the creation of a CSS style rule that specifies how required fields should be presented to the user. Property required can have one of two possible boolean values. We use pseudo classes :required and :optional that correspond to these two values. We then specify the CSS style to be used for :required and :optional using the syntax defined in CSS3 for associating style rules with pseudo classes.

When property readonly on an instance node becomes true , the XForms processor sets controls bound to this node to have pseudoclass :required ; similarly, when property required becomes false , controls bound to that node get pseudoclass :optional . The CSS-aware browser can then use this information to update the presentation. For the case of the specialized volume control described in Figure 5.1, we use CSS pseudoclass :out-of-range to attach a special style to be used when control range is out-of-sync with the underlying data. Notice that this out-of-sync condition can also arise with control select1 when the displayed choices are a subset of the permissible values and the underlying instance holds a permissible value outside this subset.

We list the proposed CSS3 pseudoclasses with their corresponding XForms model properties in Table 5.1 and show an example of their use in Figure 5.2. Note that these pseudoclasses are being defined jointly by the CSS and XForms working groups and might be updated in the future.

Figure 5.2 CSS style rules using pseudoclasses.

 <  style   xmlns:xf  ="http://www.w3.org/2002/xforms">   @namespace xf url(http://www.w3.org/2002/xforms);   /* Red background on all invalid form controls */   *:invalid {background-color:red; }   /* Red asterisk after all required form controls */   *:required::after {content: "*"; color:red; }   /* Do not render non-relevant form controls */   *:disabled {visibility: hidden; }      /* Display non-relevant repeat items   in the system GrayText color */   *::repeat-item:disabled {   visibility: visible; color: GrayText;} </  style  > 

Table 5.1. CSS3 Pseudoclasses and the Associated XForms Model Properties

Property	CSS3	CSS3
readonly	:readonly	:readwrite
required	:required	:optional
relevant	:enabled	:disabled
constraint	:valid	:invalid
	:out-of-range

5.2 Attaching Constraints Via Element bind

Model properties are created via element bind . We encountered this element when creating binding sites in Section 3.2.2. ^[1] The bind element is also used for attaching model properties to a set of nodes in the instance. When used in this manner, element bind specifies the set of nodes to which the property is being applied via XForms binding attributes. All allowed model properties are legal attributes on element bind ; model properties are applied by specifying an appropriate attribute-value pair. Thus, element bind has the following general form:

^[1] With the benefit of hindsight, we should probably have named this assert , that is, it was probably a mistake to overload element bind to play both roles, and this may well be revisited in a future version of XForms.

nodeset	Locates set of nodes to which a model property is to be applied. The specified property will be applied to each node in the node-set.
property	The name of the property to be applied.

Model property bindings created via bind can be collected inside a container bind element for authoring convenience. When collected inside a bind container, this container can use XForms binding expressions to define the evaluation context for the binding expressions that appear within contained bind elements. We show a template bind in Figure 5.3.

Figure 5.3 Element bind is used to attach model properties.

 <  model   xmlns  ="http://www.w3.org/2002/xforms">   <  instance  >     <  root   xmlns  ="">       <  c1  ><  c11  /><  c12  /></  c1  >       <  c2  ><  c21  /><  c22  /></  c2  >   </  root  ></  instance  >   <  bind   nodeset  ="/root">     <  bind   nodeset  ="c1/c11"  required  ="value"/>     <  bind   nodeset  ="*"  type  ="xsd:string"/> </  bind  ></  model  >