| home / programming / xforms / |    [previous] [next] |
|
|
|
Figure 2-5 shows the user interface that results from this portion of the XForms code, with the first line item highlighted.
|
|
Like xforms:itemset seen earlier,
xforms:repeat causes a repetition of content, once
for each node in a given set of nodes--exactly the behavior needed to populate
the u:OrderLine elements from UBL. All the content
of xforms:repeat is effectively duplicated as many
times as there are line items, which can be dynamically added and removed. The
first form control on each line item is xforms:range,
which allows a smoother way to select a value than typing a number; for example,
a sliding indicator. The range here is from 1 to 9.
The rest of the repeating form controls are similar to ones already
used in this example. One difference is the class attribute on the final xforms:input,
which is used by the associated CSS to style the form control.
Outside of the repeat, a few interesting things are happening.
Inside another group, an xforms:trigger is configured
to insert a new line item. Another declarative action, xforms:insert,
accomplishes this feat. The location of the inserted line item is either just
before or just after a specific location (from the at
attribute) within a particular node-set (from the nodeset
attribute).
The xforms:delete action works similarly.
Any repeating set keeps track of the currently active item, called the index.
Both the insert and delete actions make use of the index, as obtained through
the index( ) function.
The concluding part of the sample document, in Example 2-8, allows the completed document to be written to disk.
Example 2-8: XForms markup to submit the data
<xforms:submit submission="submit"><xforms:label>Write to disk</xforms:label></xforms:submit></body></html>
Figure 2-6 shows the rendering for this piece of XForms code.
|
|
The xforms:submit element is another
form control, like xforms:trigger, but able to
invoke the submission procedure without any additional coding needed. It contains
a reference to the xforms:submission element contained
in the XForms Model, which ultimately determines what happens when this control
is activated. After the last form control, the XHTML document comes to its usual
conclusion.
The philosophy of the XForms specification can be summed up in a single line, found in the Abstract of the official W3C XForms document.
XForms is not a free-standing document type, but is intended to be integrated into other markup languages, such as XHTML or SVG.
This approach has benefits as well as drawbacks. The benefits are that the XForms specification was completed more quickly, and without host language dependencies that otherwise might exist. The primary disadvantage is that more work needs to be done to actually integrate XForms with XHTML, SVG, or any other language.
Another W3C specification, Modularization
of XHTML, provides a framework in which XHTML, or any other combination
of XML-based languages, can be mixed and matched in order to provide a combined
document type. Such combinations can take advantage of specific language features;
for example, in XHTML a non-rendered head section
can contain the XForms Model, and in SVG, a foreignObject
element can enclose individual form controls.
| home / programming / xforms / | [previous] [next] |
| ||||||||||||||||||||
Created: March 27 2003
Revised: October 10, 2003
URL: http://webreference.com/programming/xforms/1
