A not match regex validation option about ideas HOT 9 CLOSED

Ahem, I forgot Validator::extend...

Validator::extend('not_regex', function ($attribute, $value, $parameters, $validator) {

    if (! is_string($value) && ! is_numeric($value)) {
        return false;
    }

    // mmm, can't use requireParameterCount as it's protected
    //$validator->requireParameterCount(1, $parameters, 'not_regex');

    return ! preg_match($parameters[0], $value);
});

from ideas.

Considering there is no way to write a "negative regex" and I have lacked this on several occasions, I'd vote for this proposal. Just for example, could be used for forbidden usernames, too weak passwords, forbidden email hosts, etc.

A few refinements to your code:

protected function validateNotRegex($attribute, $value, $parameters)
{
    // ...

    $this->requireParameterCount(1, $parameters, 'not_regex'); // 'not_regex'

    return ! preg_match($parameters[0], $value); // space after "!"
}

Meanwhile, here is how to hook custom rules into the validator:

class CustomValidator extends \Illuminate\Validation\Validator;
{
    // ...
}

app('validator')->resolver(function () {
    return new CustomValidator(app('translator'), ...func_get_args());
});

from ideas.

Seems like you've picked up a bug in Validator::extend if it can't properly use requireParameterCount

Otherwise appreciate the response and amendments.

from ideas.

Hmm, could we use the Closure::bindTo() function to solve this problem? Pretty sure that makes sense for extensions...

That way, the extension closure would have access to the validator object as $this and - if I'm not mistaken - automatically access private and protected methods.

from ideas.

I thought about this, but not sure it would be a good idea. Maybe people are using the current $this to access the class in which Validator::extend is called.

$validator is already passed to the callback, and it should be sufficient.

Nevertheless, it would be a breaking change.

from ideas.

Yes, that would be breaking backwards compatibility, but that would be okay in a major release.

I'd also argue that using the current $this is highly unlikely in a custom validator, since they're usually defined in a service provider. Even if I'm wrong (examples, please!), we'd still have the use clause.

from ideas.

Refs laravel/docs#1833.

Though, to continue discussing about this requireParameterCount / $this stuff I think it would be better to open a new issue.

from ideas.

I'm pretty much OK with this general idea.

from ideas.

PR submitted: laravel/framework#23475.

from ideas.