Sample Rules Definition File
The following is an example of an XML rules definition file that demonstrates all of the elements and attributes that are available in the xml schema. It also illustrates a number of validation types. A version of the file in JSON format which describes the exact same rules follows the XML file. The complete files are listed, followed by excerpts from the files with a more detailed description of each section.
The Complete XML File
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 |
|
JSON Format File
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 |
|
The conditions Element
1 2 3 4 5 |
|
1 2 3 4 5 6 |
|
Here we are defining one condition, and giving it a unique name of MustLikeSomething. We then specify how the condition is to be evaluated on both the server and the client.
In the case of the server we are saying:
“This condition is met when the value of getLikeCheese() is zero and the value of getLikeChocolate() is zero.”
While on the client we are saying:
“This condition is met when the value of the html element with a name attribute of LikeCheese is zero and the value of the html element with a name attribute of LikeChocolate is zero.”
Note that because we are placing actual JavaScript code into an xml attribute / json string we must escape the special characters.
This condition, MustLikeSomething will be used in a rule definition later in the file.
The contexts Element
1 2 3 4 |
|
“contexts” : [ {“name”:“Register”,“formName”:“frmRegister”}, {“name”:“Profile”,“formName”:“frmProfile”} ]
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
1 2 3 4 5 6 7 8 |
|
- The descriptive name of the property is Email Address.
- The UserName property is required, and must be a valid email address.
- Both rules apply to all contexts. Note that you can indicate that a rule belongs to all contexts by specifying contexts=“*” or by simply leaving the context attribute out of the definition.
- If the UserName does not contain a valid email address, the message “Hey, buddy, you call that an Email Address?” should be returned.
1 2 3 4 5 6 |
|
1 2 3 4 5 6 7 8 9 10 |
|
- The Nickname property will be tested on both the client and the server. On the server the method CheckDupNickname(), which resides in the User Business Object, will be evaluated. On the client, an ajax call will be made to the url CheckDupNickname.cfm, with the result being evaluated by the jQuery plugin.
- The custom rule applies to all contexts (because the contexts attribute is missing).
- If the custom validation fails, the message “That Nickname is already taken. Please try a different Nickname.” should be returned.
1 2 3 4 5 6 7 |
|
1 2 3 4 5 6 7 8 9 10 11 |
|
- The descriptive name of the property is Password.
- The UserPass property is required, and must be between 5 and 10 characters long.
1 2 3 4 5 6 |
|
1 2 3 4 5 6 7 8 9 10 |
|
- Note that although the descriptive name of the property is Verify Password, whereas the property name is VerifyPassword (without a space), we do not have to supply a desc attribute in this scenario as the framework is smart enough to add appropriate spaces when a property name is camelCased.
- The VerifyPassword property is required, and must be the same as the UserPass property.
1 2 3 |
|
1 2 3 4 5 |
|
- The name of the form field which will contain the value to be evaluated is UserGroupId.
- The UserGroup property is required.
1 2 3 4 5 6 7 |
|
1 2 3 4 5 6 7 8 9 10 |
|
- The Salutation property is required, but only in the context of Profile.
- The Salutation property must conform to a regular expression.
- If the Salutation does not conform to the regular expression, the message “Only Dr, Prof, Mr, Mrs, Ms, or Miss (with or without a period) are allowed.” should be returned.
1 2 3 |
|
1 2 3 4 5 |
|
- The FirstName property is required, but only in the context of Profile.
1 2 3 4 5 6 |
|
1 2 3 4 5 6 7 8 9 10 |
|
- The LastName property is always required in the context of Profile, and is also required in the context of Register, but only if a FirstName has also been specified.
1 2 3 4 5 |
|
1 2 3 4 5 |
|
- The descriptive name of the property is What do you like?.
- The LikeOther property is required in all contexts, but only if the condition MustLikeSomething evaluates to true. Note that that condition was defined in the conditions element described above.
- If the LikeOther is not provided, the message “If you don’t like Cheese and you don’t like Chocolate, you must like something!” should be returned.
1 2 3 |
|
1 2 3 4 5 |
|
- The descriptive name of the property is How much money would you like?.
- The HowMuch property must contain a numeric value.
1 2 3 4 5 6 7 8 |
|
1 2 3 4 5 6 7 8 9 10 11 12 |
|
- The descriptive name of the AllowCommunication property is May we send you information?. Note that this property does not have any rules assigned to it, but is being defined so that the rule that makes use of it (defined on the CommunicationMethod property) can generate a friendly validation failure message.
- The CommunicationMethod property is required in all contexts, but only if the AllowCommunication property has been assigned a value of 1.
- If the CommunicationMethod is not provided, the message “If you are allowing communication, you must choose a communication method.” should be returned.