Let's start with a simple example that demonstrates the functionality of XForms.
Let's look at this line by line. The first basic rule when dealing with XForms is that they cannot exist as independent entities; instead, they're designed to be integrated with XHTML (or other markup) documents. This is why the XForm above is enclosed within a regular XHTML document, and why the XHTML namespace has been referenced at the top.
Note that in addition to the XHTML namespace, when dealing with XForms, you'll also need to specify the XForms namespace, which is currently "http://www.w3.org/2002/xforms/cr".
The second basic rule when working with XForms is this: every XForm consists of two primary components, a form model (which specifies functionality) and one or more form controls (which handle presentation). The form model, indicated by the <xforms:model> element, defines what the form does. This model defines the data to be captured/modified by the form as well as the logical components that govern how the form behaves on user interaction (including where the form should be submitted and how to handle the various form events). The model also includes information on the bindings between the form controls and the instance data, and can optionally link to external XML Schemas for validation purposes. The <xforms:model> element is usually accompanied with an "id" attribute, which contains a name for the model. This name is used by the form controls in order to link the interface section of the form to the correct form model. Obviously, this also means that you can have multiple models with a single XHTML file, and link to each one by its name. Additionally, since the form model only defines how the form works and has nothing to do with its presentation, it can easily be reused, either within the same application or in other applications or platforms. Typically, the <xforms:model> element appears within the <head> of the document, and encloses an <xforms:instance> element.
The <xforms:instance> element defines the "instance data" for the form This instance data is an XML tree representation of the values associated with the form, and it can be defined inline (as above) or imported from an external XML file. In this case, the XML structure is pretty simple: a single root element called <user> encompassing one child element called <name>. Normally, the <xforms:model> element would also contain information on where the form is to be submitted via the <xforms:submission> element, data bindings via the <xforms:bind> element and event handlers via the <xforms:action> element. I'll be discussing those shortly, so don't worry too much about them for the moment. Once the form model has been defined, it's time to define the other half of the puzzle: the form controls, or how the form looks. XForms provides a bunch of elements to accomplish this; by and large, they map neatly into the HTML form controls you're already familiar with, and appear within the <body> of the document.
The first (and simplest) of these controls is the <xforms:input> element, which represents a text entry field. Note my use of the "model" attribute to tell the XForms processor which form model this control belongs to, and the "ref" attribute to tell it which node in the instance data tree this particular value maps to. XPath expressions are used in the latter. In case you don't know what those are, take a look at http://www.melonfire.com/community/columns/trog/article.php?id=83 and they should make a little more sense to you.
Another useful (though not often used) form control is the <xforms:output> element, which is used to display the value of a particular node from the XML instance data tree. Note again my usage of the "model" and "ref" attributes to link the control to the model and instance data tree defined in the <head> of the document. If you were to try viewing the XForm above in an XForms-capable browser, you'd see something like this:
Pretty cool, huh?
blog comments powered by Disqus |
|
|
|
|
|
|
|