We need a way to dynamically replace text tokens in a failureMessage so it can be replaced with properties from the validation rule. For example, a typical rule might look like:
<property name="Name" desc="Name">
<rule type="required" contexts="*" />
<rule type="maxLength" failureMessage="The name field can not be longer than 50 characters.">
<param name="maxLength" value="50" />
</rule>
</property>
The problem is when you write the "failureMessage" you end up having to duplicate several values based on properties in the validation rule. So if the description of the field every changes or you adjust the maxLength property and forget to mirror the changes in your failureMessage, the information becomes out of date.
What we need to is a token system that would allow us to change the failureMessage to something like:
The {property.name} field can not be longer than {rule.maxLength} characters.
(NOTE: The tokenizer should probably have some syntax for specify case. In many cases users might want to force a token's text to lower case.)
This not only makes the failureMessage more future proof, but you could use the exact same syntax for all matching validation rules, since the text would be dynamically updated with the correct text.
We need a way to dynamically replace text tokens in a failureMessage so it can be replaced with properties from the validation rule. For example, a typical rule might look like:
The problem is when you write the "failureMessage" you end up having to duplicate several values based on properties in the validation rule. So if the description of the field every changes or you adjust the maxLength property and forget to mirror the changes in your failureMessage, the information becomes out of date.
What we need to is a token system that would allow us to change the failureMessage to something like:
The {property.name} field can not be longer than {rule.maxLength} characters.
(NOTE: The tokenizer should probably have some syntax for specify case. In many cases users might want to force a token's text to lower case.)
This not only makes the failureMessage more future proof, but you could use the exact same syntax for all matching validation rules, since the text would be dynamically updated with the correct text.