Skip to content
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

Closed
matthetherington opened this issue Dec 6, 2023 · 0 comments · Fixed by #205
Closed

[Bug] Inconsistent model-level and field-level behaviour for sub-objects #204

matthetherington opened this issue Dec 6, 2023 · 0 comments · Fixed by #205
Labels
Bug Something isn't working Triage Issue needs to be triaged

Comments

@matthetherington
Copy link

matthetherington commented Dec 6, 2023

Describe the bug
With an EditContext model containing one or more sub-objects, eg a Customer which has an Address, the
FieldIdentifier.Model for the changed field will be different to the root object when Address properties have changed. For example, if Address.FirstLine changes, FieldIdentifier.Model will be of type Address, so a registered IValidator<Address> validator will be used to validate at the field-level instead of IValidator<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 the Validator 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 the IValidator<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

  • The same model-level validation rules apply to field-level validation, but scoped to the changed property.
  • If options are passed to <FluentValidationValidator>, that configuration is used to validate both the whole model and individual fields
  • If a Validator is provided to <FluentValidationValidator>, it is possible to validate sub object fields without an exception being thrown
  • If a Validator is not provided, the type of EditContext.Model is used to locate a validator instead of FieldIdentifier.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

@matthetherington matthetherington added Bug Something isn't working Triage Issue needs to be triaged labels Dec 6, 2023
matthetherington pushed a commit to matthetherington/FluentValidation that referenced this issue Dec 6, 2023
jafin added a commit to jafin/FluentValidation that referenced this issue Feb 16, 2024
jafin added a commit to jafin/FluentValidation that referenced this issue Feb 21, 2024
pwelter34 added a commit that referenced this issue Oct 7, 2024
…-field-level-validation

Fix inconsistent field-level validation (Fixes #204)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Something isn't working Triage Issue needs to be triaged
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant