Custom rules

[williamoliveira]

Is there an way of making custom rules?

[ghiscoding]

It's all in the Wiki documentation... Wiki - Regular Expression Pattern

[williamoliveira]

yeah, I saw it, but regex is now enought for me, is'nt there a way to really create new ones?

[ghiscoding]

Custom Regex is the only I have in place, it usually fit almost all situations. What are you trying to accomplish that you can't do with custom Regex?

[williamoliveira]

Well things like check the value agaist others fields

[ghiscoding]

match and different are made for that, in_list might also interest you. You can also use interpolation to dynamically build a validation. Until you provide a better example, I still don't see what's missing...

[williamoliveira]

Just saw the remote rule, I think that and interpolation will cover my needs for now, but still, there could be a way to create custom rules for better code reuse and organization

[ghiscoding]

I still can't picture your need, without a clear example, I just don't understand what you want... Giving code examples would help a lot.

Also remember one thing, this is community sharing. If you think you can help with better features and code then go ahead, I accept new commit. This is all done in my free time and I'm not getting paid for it either, though sometime I wish it would, since I spent a whole lot of time on this library.

[gsantiago]

@ghiscoding is it possible to use a function instead of a regex to create custom rules?

It would be very useful to validate the CPF (the brazilian social security) which is not possible to validate only with regex since it includes math operations.

Thanks!

[gsantiago]

Here's an example of a function that validates a CPF:

jQuery.validator.addMethod("cpf", function(value, element) {
   value = jQuery.trim(value);

    value = value.replace('.','');
    value = value.replace('.','');
    cpf = value.replace('-','');
    while(cpf.length < 11) cpf = "0"+ cpf;
    var expReg = /^0+$|^1+$|^2+$|^3+$|^4+$|^5+$|^6+$|^7+$|^8+$|^9+$/;
    var a = [];
    var b = new Number;
    var c = 11;
    for (i=0; i<11; i++){
        a[i] = cpf.charAt(i);
        if (i < 9) b += (a[i] * --c);
    }
    if ((x = b % 11) < 2) { a[9] = 0 } else { a[9] = 11-x }
    b = 0;
    c = 11;
    for (y=0; y<10; y++) b += (a[y] * c--);
    if ((x = b % 11) < 2) { a[10] = 0; } else { a[10] = 11-x; }

    var retorno = true;
    if ((cpf.charAt(9) != a[9]) || (cpf.charAt(10) != a[10]) || cpf.match(expReg)) retorno = false;

    return this.optional(element) || retorno;

}, "Informe um CPF válido");

[ghiscoding]

@gsantiago , is your question related to the original question? I actually didn't understand the original question, but yeah it might be related. If it is then I'll reopen the ticket, if not please open another issue number and let's discuss later.

@williamoliveira, you're welcome to answer as well if you see that it does fit your original question...

Thanks

[williamoliveira]

Yes, it does fit my question, the api to add new rules could be something like this:

validationService.registerRule('my_custom_rule', {
      expression: function(scope, element){
             // do the logic and return boolean
      },
      message: 'Error message'
})

[williamoliveira]

It'd be the same fashion as the remote rule but pre-registered so you can use it anywhere like "required|alpha|my_custom_rule".

But I don't know if it can be done in the architecture as it is right now.

[ghiscoding]

Ok I now understand that the custom rules that you wanted are actually calling a remote javascript function, that was the part that I was missing.

So I am reopening the issue, but I can't promise you that it will be done, neither when it could be done, but I will definitely look at it. Also to be clear, I am not accepting every feature request, this is still developed in my personal time, but if I do see a benefit, then yes I don't mind looking at it. Thanks for the feedback :)

[gsantiago]

@ghiscoding are you open for pull requests? Maybe I can work on that

[ghiscoding]

Yes I'm open to pull request, this custom function would probably be similar to the remote implementation and for that you can look at the validation-common.js file starting at line 603. Thanks

[ghiscoding]

I'm almost done with the implementation, I did some refactoring of my code prior to implement it and so it took me a bit more time than I expected. It looks like it's working as I wanted on the Directive, I also have to look at the Service and see if it works. And finally, I need to make a few Protractor tests to cover them and I should be fine. So by the end of the week, I should have it done.

The syntax will be very similar to the remote Validator (so is the implementation), so no major difference. I'm not fully decided on the Validator name yet, I was thinking to accept both of these names custom or javascript, so for example on the Directive, it would look like this:

<input type="text" class="form-control"
            name="input1"
            ng-model="vm.model.input1"
            validation="custom:vm.myCustomValidation:alt=Alternate error message|required" />

Similar to the remote as well, the custom error message can be declared with the alt: (directly in the html validation attribute) or inside the custom function. If it's declared in the custom function, then instead of returning a boolean, it would return an object as for example
return { isValid: false, message: 'custom error' };

The custom javascript function could look like this

vm.myCustomValidation1 = function() {
    var isValid = false;

    if(vm.model.input1 === "abc") {
      isValid = true;
    }

    // you can return a boolean for isValid or an objec (see the next function)
    return isValid;

    // or returned as an object if we want to include the custom error message
    // return { isValid: false, message: 'custom error' };
  }

If you have any feedback or suggestions, now is the time...

[ghiscoding]

The feature was pushed in latest release v1.4.11

You can also look at Wiki - Custom Validation function, it's implemented exactly like I said in my previous comment.