In XDIME 2 page authors can take advantage of many XForms features, including separating the data model from the forms control markup and modularization. XDIME 2 supports a processing mode that does not require the full XForms data model, but that allows the use of initial values and hidden fields.
In XDIME 2 page authors can take advantage of many XForms features, including separating the data model from the forms control markup and modularization. XDIME 2 supports a processing mode that does not require the full XForms data model, but that allows the use of initial values and hidden fields.
MCS allows for multiple models to be defined within a single XDIME page. Please note that the XDIME page must be structured such that the form controls bound to different form models do not mix with each other. This is especially important when layouts are used to control the position of form elements.
Page authors can specify whether or not MCS should use sessions when processing forms. Refer to the topic entitled State in MCS for more information.
In order to initialize form controls or provide additional hidden data during form submission, page authors can use two elements, which take an si: namespace prefix, as a simple way of providing instance data in name/value pairs.
The si:instance element is the body content of an xforms:instance element in the model for the form. It can contain one or more si:item elements. The model may appear anywhere on an XDIME page, but must be placed before any XForms elements that refer to it.
<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/2002/06/xhtml2"
xmlns:xforms="http://www.w3.org/2002/xforms"
xmlns:si="http://www.volantis.com/xmlns/2006/01/xdime2/si">
<head>
<title>Subscriber update</title>
<xforms:model id="address">
<xforms:instance>
<si:instance>
<si:item name="street">149, rue Deguy</si:item>
<si:item name="postcode">13004 Marseille</si:item>
<si:item name="country">fr</si:item>
<si:item name="hidden">subscriber_id</si:item>
</si:instance>
</xforms:instance>
</xforms:model>
</head>
<body>
....
</body>
</html>When the name attribute on the si:item matches the ref attribute on a form control, the content of the si:item element is used to initialize the control. Otherwise, it is treated as additional data to be submitted with the form. The name attribute must be unique within a si:instance element. Taking the previous example, the some input fields will be populated with the address values.
<xforms:input class="addr" ref="street">
<xforms:label class="label">Rue</xforms:label>
</xforms:input>
<xforms:input class="addr" ref="postcode">
<xforms:label class="label">Code postal</xforms:label>
</xforms:input>
<xforms:select1>
<xforms:item>
<xforms:label>France</xforms:label>
<xforms:value>fr</xforms:value>
</xforms:item>
</xforms:select1>The matching process is straightforward for the input elements xforms:input, xforms:secret and xforms:textarea.
In select controls, the si:item content should additionally match one of the possible item values. If the content does not match a valid value, the default selection is used.
For an xforms:select1 element, the content is treated as the initial value of the control. In the case of an xforms:select element, the body content is interpreted as a comma separated list of values. If a value matches that of one of the items, which item is marked as selected.
Authors can use multiple submit controls in forms, by associating each button with an xforms:submission element. Each submit button may have a different ref and/or value attribute, so it is possible for the form handler to determine which button was used to submit the form.
For WML devices, the value attribute may be used to differentiate the buttons. It specifies the value to set in the submitted form. If it is not present, then the content of the xforms:setvalue element is used as the value. If the content is empty, then it is equivalent to specifying a value attribute as an empty string. For devices other than WML such as HTML, XHTML, XHTMLMobile, XHTMLBasic, etc., the content of the xforms:label element is used as the value of the ref attribute.
Let's consider the following example.
<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/2002/06/xhtml2"
xmlns:si="http://www.volantis.com/xmlns/2006/01/xdime2/si"
xmlns:xforms="http://www.w3.org/2002/xforms"
xmlns:ev="http://www.w3.org/2001/xml-events">
<head>
<title>xforms:setvalue</title>
<xforms:model id="form">
<xforms:instance>
<si:instance>
<si:item name="hidden">123</si:item>
</si:instance>
</xforms:instance>
<xforms:submission action="response.jsp" id="submit"/>
</xforms:model>
</head>
<body>
<p>
<xforms:submit submission="submit">
<xforms:label>button1</xforms:label>
<xforms:setvalue ev:event="DOMActivate" ref="btype" value="bt1"/>
</xforms:submit>
<xforms:submit submission="submit">
<xforms:label>button2</xforms:label>
<xforms:setvalue ev:event="DOMActivate" ref="btype" value="bt2"/>
</xforms:submit>
</p>
</body>
</html>For WML devices, if the user presses button1, then the btype=bt1 parameter will be added to the request, and the URL will have the following form:
http://localhost:8080/mcs/response.jsp?hidden=123&vform=s0&btype=bt1If the users presses button2, then btype=bt2 will be added to the request. In this case the URL will be similar to the following example:
http://localhost:8080/mcs/response.jsp?hidden=123&vform=s0&btype=bt2For devices other that WML, if the user presses button1, then the btype=button1 parameter will be added to the request, and the URL will have the following form:
http://localhost:8080/mcs/response.jsp?hidden=123&vform=s0&btype=button1If the user presses button2, then btype=button2 will be added to the request, and the URL will look like this:
http://localhost:8080/mcs/response.jsp?hidden=123&vform=s0&btype=button2It is also possible to discriminate on the basis of the ref attribute.
<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/2002/06/xhtml2"
xmlns:si="http://www.volantis.com/xmlns/2006/01/xdime2/si"
xmlns:xforms="http://www.w3.org/2002/xforms"
xmlns:ev="http://www.w3.org/2001/xml-events">
<head>
<title>xforms:setvalue</title>
<xforms:model id="form">
<xforms:instance>
<si:instance>
<si:item name="hidden">123</si:item>
</si:instance>
</xforms:instance>
<xforms:submission action="response.jsp" id="submit"/>
</xforms:model>
</head>
<body>
<p>
<xforms:submit submission="submit">
<xforms:label>button3</xforms:label>
<xforms:setvalue ev:event="DOMActivate" ref="btype3" value="1"/>
</xforms:submit>
<xforms:submit submission="submit">
<xforms:label>button4</xforms:label>
<xforms:setvalue ev:event="DOMActivate" ref="btype4" value="2"/>
</xforms:submit>
</p>
</body>
</html>For WML devices, if the user presses button3, then the btype3=1 parameter will be appended to the request. If button4 is pressed, then the btype4=2 parameter will be added to the request. For devices other than WML, the content of the xforms:label element will be used as the value of the ref attribute. In other words, the btype3=button3 or btype4=button4 parameter will be added to the request.
It is good practice to use server-side form validation for all events since not all devices support a full range of client-side validation features, and some may be incapable of supporting any validation at all.
However, where it is supported, authors can make good use of client-side validation to improve the quality of data submitted by users. It also avoids the need to repeatedly send a form to the server for error checking.
The mcs-input-format property specifies the validation pattern. Alternatively authors can apply the property in a style attribute, for example.
<xforms:input style='mcs-input-format:"M:A*a"'>See Specifying data types and validation criteria and Validating form input for details.