previous   next   contents

8 Binding


Contents

This chapter is normative.

8.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 is specified through the use of binding expressions. The syntax and details of binding expressions are defined in the Dynamic Constraint Language chapter. This chapter describes the wider topic of how binding expressions are used within XForms.

A future revision of this chapter will address binding across XForms Models, for instance declaring an "address" in one XForms Model and referencing it from another.

[Editor's Feedback Request 8.1.binding: Examples in this chapter heavily lean towards binding between form controls and instance data. Future revisions of XForms will include greater representation of binding between form controls and the XForms Model. Feedback on this chapter is especially appreciated.]

8.2 Binding Attributes

XForms defines an attribute ref that can be placed on any form control. Note that 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 
<xform:textbox ref="binding-expression">
   <xform:caption>Your first name</xform:caption>
</xform: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" xform: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 the operation of binding expressions are given throughout the rest of this chapter.

8.3 Direct Binding

When a containing document has at most a single XForms Model and at most 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 
<xform:textbox ref="orderForm/shipTo/firstName">
...

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

Here is the matching instance data for the above example.

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 
<xform: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 instance data for the above example.

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

Note also that:

8.4 Indirect Binding

In situations where a form is designed by collaboration (such as between a graphic designer and a database/XML specialist) it is desirable to locate all binding expressions in a single area in the containing document. 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 
<xform:textbox ref="id('myfirstname')">
...

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

Here is the instance data for the above example.

This accomplishes the following:

8.5 Multiple Forms per Page

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

By default, binding expressions are based on an XForms Model or instance data that are children of the first <xform> element in document order. To refer to the contents of subsequent <xform> elements, these must be decorated with id attributes of type xsd:ID. Attached to the form control element, an additional attribute xform serves to adjust the context node for the attached binding expression to the virtual instance data or XForms Model associated with the <xform> element with the matching id.

For example:

Binding Expression Specifying Non-default <xform> 
<xform:textbox xform="b" ref="/orderForm/shipTo/firstName">
...

Here the xform and ref attributes specify a binding to the instance data and XForms Model.
Instance Data 
<xform:xform id="b">
  <xform:model>
    ...
  </xform:model>
  <xform:instance>
    <orderForm xmlns="...">
      <shipTo>
        <firstName>value</firstName>
      </shipTo>
    </orderForm>
  </xform:instance>
</xform:xform>

Here is the markup for the above example.

Scoped resolution of binding expressions, as defined in the Dynamic Constraint Language chapter can in some cases be used to avoid repetitive uses of the xform attribute.

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