Validator Editor PHP

Validator Editor PHP

rf1234rf1234 Posts: 2,991Questions: 87Answers: 421

I use multiple front end editors with the same back end editor instance.

This causes problems with validators:
If a field is not set built-in validators just return true and don't seem to do the validation check.
Custom validators don't work this way: I must explicitly check whether the variable was set. Otherwise I get an error message that causes a crash at the front end because the javascript editor doesn't know the variable that returned the error.

Can this be fixed please: custom validators should behave the same way as built-in validators when it comes to fields that are not sent from the client.

So this works:

Field::inst( 'fieldNotSentFromClient' )
    ->validator( 'Validate::notEmpty', array('message' => "field may not be empty") )

This does not work:

Field::inst( 'fieldNotSentFromClient' )
    ->validator( function ( $val, $data, $opts ) {
        if ( $val <= '') {
            return "field may not be empty";
        }
        return true;
    })

This works as well:

Field::inst( 'fieldNotSentFromClient' )
    ->validator( function ( $val, $data, $opts ) {
       if ( ! isset($val) ) {
           return true;
        }
        if ( $val <= '') {
            return "field may not be empty";
        }
        return true;
    })

This question has an accepted answers - jump to answer

Answers

  • allanallan Posts: 63,498Questions: 1Answers: 10,471 Site admin
    Answer ✓

    The built in validators do actually run, but they are passed through this function. It performs common checks based on the validation options, and by default that is that the field is valid if not submitted.

    It isn't done that way with the custom validator since it doesn't perform any common validation - that would be up to yourself if you wanted to add that or not. The idea of the custom validator was that it would be entirely up to you want validation code ran.

    Does that make sense now?

    Allan

  • rf1234rf1234 Posts: 2,991Questions: 87Answers: 421

    Well, it is a design decision. I wouldn't design it that way because I think it is counter intuitive. It is up to you! But now I know what the difference is. Took me a while to figure this out.

    Roland

This discussion has been closed.