-
-
Notifications
You must be signed in to change notification settings - Fork 826
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Validator extender #2102
Validator extender #2102
Conversation
Could you provide a few examples / links? It's hard to think about this in the abstract. |
Really, the only/biggest question is what to do with validator extensions, as they will often require DI) |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We do this to keep the amount of open issues to a manageable minimum. |
Not stale |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The deprecation messages will need to be updated (beta13 => beta14)
Regarding the code of the test, I'm not sure whether we want to explain what it does or simplify it? I believe it's copied from one of my example and the reason it's so complex is to keep the additional password rules that might have been made by other extensions. I think having a comment reminding that would be useful for future readers.
Or we could also use a shorter code that blindly replaces the rules without regard for other extensions. This might be something legitimately used in the local extend.php
when the list of extensions is well known. Something like: (untested)
$this->extend((new Extend\Validator(UserValidator::class))->configure(function ($validator) {
$validator->setRules([
'password' => [
'required',
'min:8'
]
] + $validator->getRules());
}
}));
I think it would still make sense to pass the Flarum validator object to the callback. It could be the second param instead of the first like it was with the event. Sometimes values are stored on that object, for example the user instance on UserValidator
.
There's also the not-exactly-related-but-somewhat-close matter of #2398 where an event might or might not make sense (?)
721d08e
to
299b60a
Compare
- Provide both flarum and laravel validator to validator configure extender - Simplify integration test example - Add integration test with invokable class.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have not tested locally, but this looks good 👍
Should the tests cover calling a callback/class that takes a single argument? This is something that should work in PHP? One of the two (callback or class) could omit the second argument on purpose (with a comment explaining it's omitted)
Fixes part of #1891
Changes proposed in this pull request:
Reviewers should focus on:
I slightly deviated from the previously discussed spec on this one, as I think that having a configure method that runs the validator through a callable gives us and developers more flexibility than simply the ability to add rules. Similarly, there are extensions that depend on this type of capabilities.
Should there be a dedicated method to run the ruleset through a callable as well? I'm not sure if that is necessary (this PR supports that), but it might be a nice shortcut.
Confirmed
composer test
).