You can use client- and/or server-side validation to improve the quality of data submitted by users. Client-side validation avoids the need to repeatedly send a form to the server for error checking. However, not all devices support a full range of client-side validation features, and some may be incapable of supporting any validation at all. So it is good practice to use server-side form validation in all events.
You can use client- and/or server-side validation to improve the quality of data submitted by users. Client-side validation avoids the need to repeatedly send a form to the server for error checking. However, not all devices support a full range of client-side validation features, and some may be incapable of supporting any validation at all. So it is good practice to use server-side form validation in all events.
However, where it is supported, you 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.
You can also specify data types for form input elements in order to improve the user experience of entering data into a form and the quality of the submitted data. Refer to the topic entitled Specifying data types and validation criteria for more information.
The xftextinput element has several attributes that support validation.
The maxLength defines the maximum number of characters allowed in a field. Because some validation patterns effectively define the maximum length of valid input, you may not need to use this attribute.
Validators are expressions that define the content patterns for input fields, and specify whether data must be provided or not. You use a validator in the optional validate attribute.
In the errmsg attribute you can define a message to display if the field fails validation.
You can also use the mcs-input-format property.
In XDIME 2 you use the mcs-input-format property to specify validation rules. Please note that this property works only on devices that support XHTML Mobile Profile protocol and WCSS (Wireless CSS) validation.
You may also use widgets to validate input in XForms elements. The Simple Forms Validator widget checks if the value in a single XForms field is valid. The Multiple Forms Validator checks that the values in multiple fields, taken together, meet some specified constraints. Refer to 4.5. Validating a form and 5.4. Validating multiple forms in the Using the widget library tutorial for further information. Please note that this validation method is limited to devices which support the Client Framework 1.
You use the mcs-input-format style property to specify the validation pattern.
<xforms:input style='mcs-input-format:"M:A*a"'>The following tables show client-side validator patterns for MCS forms.
A validator consists of a prefix separated by a colon (:) from the pattern, for example M:x*x. The prefix determines the data type of the validator and whether it is required or not. An uppercase prefix means that the input is required, and a lowercase prefix means that it is optional.
| Prefix | Example | Description |
|---|---|---|
| M | M:X*X | One or more uppercase alphabetic characters of any type |
| N | n:### | Optional, three numeric characters |
| P | P:+##-####-###### | A required telephone number with a country code |
| D | d:DD-MM-YY | An optional date |
The pattern following the prefix indicates the validator type. Here, the uppercase and lowercase mean that the pattern is case sensitive. The length is also defined by the pattern unless the wildcard match of '*' is specified.
| Character | Example | Description |
|---|---|---|
| M | M:M*M | Validation not required |
| X | M:x*x | Mixed characters of any type |
| A | M:A*a | Alphabetic and punctuation characters |
| # | N:#### | Numeric value |
| * | M:A*a | The preceding character can be matched zero or more times. A character followed by a '*' and followed by the same character again indicates that the character must occur one or more times. |
Date and time pattern characters have these meanings in the context of a 'D' prefix.
| Character | Example | Description |
|---|---|---|
| Y | D:YYYY | Year number, normally used in pairs or as a group of four |
| M | D:MM | Month number, in the range 1-12, normally used in pairs |
| D | d:DD | Day number, in the range 1-31, normally used in pairs. Valid values depend on the maximum days in the related month. Leap year logic is applied for February. |
| / | D:DD/MM | Date separator |
| - | D:YYYY-MM-DD | Date separator |
| H | d:HH:MM | Hour number, normally used in pairs. The range is 00 to 23 for a 24-hour clock and from 1 to 12 for 12-hour clock. |
| M | D:MM | Minute number, normally used in pairs, with a range of 00 to 59. |
| S | D:MM:SS | Second number, normally used in pairs, with a range of 00 to 59. |
| : | d:MM:SS | Time separator |
| a | D:HH:MM a | Optional PM indicator used to validate 12-hour clock values. If the time is after 1200 on the 24-hour clock, the matching content must be 'PM', otherwise it must not be present. For example, if the pattern is D:HH:mm a, values of '11:23 PM' or '11.23' are valid, whereas '11.23' AM or '23.23' are invalid. |
These pattern characters have these meanings in the context of a 'P' prefix.
| Character | Example | Description |
|---|---|---|
| + | P:+##-##-####-#### | Phone number country code |
| - | P:##-####-#### | Phone number separator |