-
-
Notifications
You must be signed in to change notification settings - Fork 87
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
[Bug] Inconsistent model-level and field-level behaviour for sub-objects #204
Comments
Edit: I tried your PR and it didn't seem to make any difference, so nevermind, the two things are not related. Hi @matthetherington! I'm having an issue where I have a model that contains a list of sub-items like such:
I have a case where I have a list of items, and only the selected items should be validated. The selected items have some inputs etc, so they are validated with their own validator. But I have an issue where if I select an item, input bad data so that it gives an error, and then unselect the item. The error doesn't seem to go away. Even when calling But if I call editContext.Validate(), it seems to do the trick. But I'd rather just update the one field that needs updating, because the Validate() will show errors for all of the other inputs that the user might've not gotten to yet. Is this related to your bug ? |
…-field-level-validation Fix inconsistent field-level validation (Fixes #204)
Describe the bug
With an EditContext model containing one or more sub-objects, eg a
Customer
which has anAddress
, theFieldIdentifier.Model
for the changed field will be different to the root object whenAddress
properties have changed. For example, ifAddress.FirstLine
changes,FieldIdentifier.Model
will be of typeAddress
, so a registeredIValidator<Address>
validator will be used to validate at the field-level instead ofIValidator<Customer>
like at the model-level.This means an exception is thrown when blurring out of Address fields if an
IValidator<Customer>
is provided to<FluentValidationValidator>
via theValidator
property.If a Validator is not provided, and one is instead retrieved from DI / assembly scan, then any rules affecting the
Address
that are defined on theIValidator<Customer>
validator will not be executed, leading to inconsistent behaviour between model-level and field-level validation.Also, when validating at the field-level, any configuration provided to the mounted
<FluentValidationValidator>
component (eg RuleSets) is ignored. The RuleSet will be used for whole-model validation, but ignored for field-level validation, as the configuration is not passed to the validator. At the field-level, rules are executed purely based on the property name, ignoring other configuration.To Reproduce
I've put together a small Blazor Server app to demonstrate the issues: https://github.com/matthetherington/BlazoredFluentValidationIssueDemo
Expected behavior
<FluentValidationValidator>
, that configuration is used to validate both the whole model and individual fields<FluentValidationValidator>
, it is possible to validate sub object fields without an exception being thrownEditContext.Model
is used to locate a validator instead ofFieldIdentifier.Model
, so that rules defined on the root-level validator are ran.In the demo app, I've put together a proposal for how it could behave - pages suffixed with "Fixed" use a modified version of Blazored.FluentValidation with the changes in #205
Screenshots
N/A
Hosting Model (is this issue happening with a certain hosting model?):
N/A
The text was updated successfully, but these errors were encountered: