previous   next   contents

9 Binding


Contents

This chapter is normative.

9.1 Introduction

Binding is the glue that connects the separate pieces of XForms -- the XForms Model, instance data, and form controls. The binding is independent of the language used in the XForms Model (Schema or simple syntax) and also independent of the user interface language used.

Binding has been designed with the following design rationale:

  1. Authoring simplicity ("keep the simple things simple and the hard things possible")
  2. Leveraging of existing standards, like XPath and XLink
  3. support for multiple instances per XForms Model
  4. support for multiple XForms Models per document
  5. protocol independence (notably tricky for multiple instances)

A future revision of the binding specification will address reuse across XForms Models, for instance declaring an "address" in one place and reusing it in another.

9.2 Binding Attributes

XForms defines an attribute ref that can be placed on any form control. When placed on form controls outside of XForms, it must be appropriately namespaced. The value of the attribute is a binding expression, based on the XForms Dynamic Constraints Language, that links the form control to a particular location in the instance data (and therefore a particular model item). For example:

XForms User Interface Markup with Binding Attributes 
<xfm:textbox ref="binding-expression">
   <xfm:caption>Your first name</xfm:caption>
</xfm:textbox>
The ref attribute links the form control to the instance data and XForms Model declared elsewhere in the containing document.

This can also be used on non-XForms form controls, for instance XHTML:

XHTML with Binding Attributes 
<html:input type="text" name="ncname" xfm:ref="binding-expression" />
Here the ref attribute links an XHTML form control to the instance data and XForms Model contained elsewhere in the containing document. Note that the html: prefix is used here to represent the XHTML namespace.

Details on legal binding expressions are given throughout the rest of this chapter.

9.3 Binding in the Presence of a Single Model

When a containing document has only a single XForms Model and a single set of instance data, binding is simpler because there is no possibility of ambiguity as to which XForms Model and instance data will participate. The following syntax can be used for the binding expression:

For example:

Binding Expression with an XForms Dynamic Constraint 
<xfm:textbox ref="orderForm/shipTo/firstName">
...

Here the ref attribute specifies a path through the instance data to the desired location.
Instance Data 
<orderForm>
  <shipTo>
    <firstName>value</firstName>
  </shipTo>
</orderForm>

Here is the optional instance data for the above example.

Note that the binding expression implies the structure of the instance data.

A special case applies when binding to an element in the instance data that contains an attribute of type xsd:ID. In this case, an XPath function id() , can be used:

Binding Expression with XPath id() Syntax 
<xfm:textbox ref="id('myfirstname')">
...

Here the ref attribute specifies a link to an instance data element with an id of myfirstname.
Instance Data 
<a>
  <b id="myfirstname">value</b>
</a>

Here is the required instance data for the above example.

For this syntax to be valid, the following conditions must be true:

Note also that:

9.4 Binding in the Presence of Multiple Models

One design goal of XForms is to support multiple forms per page. This is accomplished by having multiple XForms Models within a containing document. Each XForms Model might have separate instance data defined. This makes binding slightly more complex, because the correct instance data elements need to be referenced.

[Ed. The case where a single XForms Model has more than one instance data section is not dealt with in this revision of the specification. The Working Group is discussing ways to accomplish this. Additionally, when discussing how to describe repeating structures (arrays), we have to revisit this.]

The default context node for a binding expression is the first <instance> element in document order. To indicate a different instance, binding expressions can use a syntax similar to XPath axis specifiers. The axis specifier is instance::, and serves to reset the context node for the remainder of the binding expression to the <instance> element with the matching id. The binding expression is in error if there is no matching id. For example:

Binding Expression Specifying Non-default Instance Data 
<xfm:textbox ref="instance::b/orderForm/shipTo/firstName">
...

Here the ref attribute specifies a link to an instance data element with an id of myfirstname.
Instance Data 
<xfm:instance href="..."/>
<xfm:instance id="b">
  <orderForm>
    <shipTo>
      <firstName>value</firstName>
    </shipTo>
  </orderForm>
</xfm:instance>

Here is the instance data for the above example.

In cases where there is no explicitly specified instance data, the model:: axis can be used to select the virtual instance data associated with an XForms Model.

[Ed. This syntax is under discussion and does not yet have full Working Group consensus.

In many cases, it may be undesirable for the user interface markup to refer to specific instance data identifiers or contain lengthy binding expressions. XForms allows the binding expression to appear in a separate element <bind>, a sibling to <model> and <instance>.

The attributes of <bind> are id of type xsd:ID and ref which takes a binding expression. When a binding expression is defined this way, the form control can reference the id of the <bind> element, as seen here:

Binding Expression Using Indirection 
<xfm:textbox ref="id('myfirstname')">
...

Here the ref attribute specifies a link to a binding expression defined elsewhere.
Instance Data 
<xfm:bind id="myfirstname" ref="orderForm/shipTo/firstName""/>
<xfm:instance>
  <orderForm>
    <shipTo>
      <firstName>value</firstName>
    </shipTo>
  </orderForm>
</xfm:instance>

Here is the instance data for the above example.

The binding expression used on the form control looks suspiciously like our first example. So, what have we actually won?

Acknowledgments: The editor would like to thank Kai Scheppe, Malte Wedel and Götz Bock for lots of constructive criticism on early versions of this document and their contributions to its present content.

previous   next   contents