OK, I'm finally starting to get somewhere with this error!
Right, to start with, I added my
custom regex to the
base rules, straight after the
email rule in the file
validator.php and renamed the handler by appending the number 1 to my custom handler like:
$baseRules["decimal4to21"] = array(
"#regex" => '/^[0-9]{0,2}(\.[0-9]{0,2})?$/',
"alertText" => LI_PREFIX . addslashes(JText::_("JSTORESOCIAL_FORMVALIDATOR_THIS_IS_NOT_A_VALID_EMAIL")), //JSTORESOCIAL_VALIDATOR_MUST_BE_22_DIGITS
);
I then changed the handler in my my form's XML so that it would use this rule from the validator instead of my custom rule file.
This
works perfectly to validate/invalidate exactly according to my regex and therefore proves that there MUST be a difference in how custom rules are handled/rendered on the page compared with base rules.
This prompted me to look at the difference and here's what I found:
For note, the only difference is that BASE rules appear in the script for my layout without single quotation marks (' ') around it resulting in the rule looking like:
"decimal4to21" : {
"regex" : /^[0-9]{0,2}(\.[0-9]{0,2})?$/,
"alertText" : '<span class="msg-prefix">• </span>This is not a valid email'
}
AS OPPOSED TO:
jQuery(document).ready(function(){var el = jQuery("#jform_test");el.validationEngine("showPrompt", "Decimal", "pass", false);});
jQuery.validationEngineLanguage.allRules.decimal4to2 = {
"regex" : new RegExp("^[0-9]{0,2}(\.[0-9]{0,2})?$", ''),
"alertText" : '<span class="msg-prefix">• </span>Must be 2.2 digits'
}
where it is creating a
new rule Object. Also, please note the fact that all of the
base rules are rendered
wrapped with a slash (/) where as
custom rules are not. I also tried changing my custom rule by prepending and appending a / but this doesn't work.
@admin, Please could you take a look at this as it appears as if
custom rules need to be rendered just like base rules (as described above) to work correctly?
I found that this behaviour is not limited to just decimal fields as I first thought. The incorrect behaviour of the custom regular expressions is also evident in string/varchar fields.
Many thanks,
Gez