UniMichael
commented
11 months ago EDIT: You can ignore this comment. I messed something up when I tried the PR. It's working fine as far as I can tell.
Was asked to provide some feedback in #180, since we ended-up making our own validation handler at work to tackle something similar.
From playing around with it, it does seem to properly validate nested objects' fields, though it's worth pointing-out that it doesn't address the problem discussed in #180 (all RuleSets firing, regardless of options), but it's like I said in that discussion:
FluentValidation's API doesn't expose the necessary functions to fix that (which is why our fix at work validates the entire model on field change and only tracks the new validation errors so we can fake a field-speicific validation).
If anyone's interested in trying to fix that specific issue with this PR, here's the basic example I was using to reproduce it:
public class Person
{
public string Name { get; set; } = string.Empty;
public int Age { get; set; }
public Address Address { get; set; } = new();
}
public class Address
{
public string Street { get; set; } = string.Empty;
public string Country { get; set; } = string.Empty;
public string PostalCode { get; set; } = string.Empty;
}
public class PersonValidator : AbstractValidator<Person>
{
public PersonValidator(IValidator<Address> addressValidator)
{
RuleFor(a => a.Address).SetValidator(addressValidator);
RuleFor(p => p.Name).NotEmpty().WithMessage("Name required");
RuleSet("Adult", () =>
{
RuleFor(p => p.Age).GreaterThan(18).WithMessage("Must be an adult");
});
}
}
public class AddressValidator : AbstractValidator<Address>
{
public const string PostalCodePattern = "[a-zA-Z][0-0][a-zA-Z] [0-9][a-zA-Z][0-9]";
public static readonly Regex PostalCodeRegex = new(PostalCodePattern);
public AddressValidator()
{
RuleFor(a => a.Country).NotEmpty().WithMessage("Country required");
RuleFor(a => a.Street).NotEmpty().WithMessage("Street required");
RuleFor(a => a.PostalCode).Matches(PostalCodeRegex).WithMessage("Must be valid postal code");
RuleSet("Canadian", () =>
{
RuleFor(a => a.Country)
.NotEmpty().WithMessage("Country required")
.Equal("Canada").WithMessage("Must be Canadian");
});
}
}@page "/"
@using Microsoft.AspNetCore.Components.Forms
@using BlazorServerApp.Models
@using Blazored.FluentValidation
<EditForm Model="_person" OnValidSubmit="() => { }">
@* NOTE: The options' rulesets are basically ignored, you can use whatever RuleSet you want, and it'll still run all of them *@
<FluentValidationValidator Options="@(options => options.IncludeRuleSets("default"))"/>
<ValidationSummary/>
<h1>Person</h1>
<div>
<label>Name</label>
<InputText @bind-Value="_person.Name"/>
</div>
<div>
<label>Age</label>
<InputNumber @bind-Value="_person.Age"/>
</div>
<h2>Address</h2>
<div>
<label>Country</label>
<InputText @bind-Value="_person.Address.Country"/>
</div>
<div>
<label>Street</label>
<InputText @bind-Value="_person.Address.Street"/>
</div>
<div>
<label>Postal Code</label>
<InputText @bind-Value="_person.Address.PostalCode"/>
</div>
<button type="submit">
Submit
</button>
</EditForm>
@code {
private readonly Person _person = new();
}
matthetherington
Albiniivari
etarvt
Xavia1991
psandler
ckirker
DaveVW-AWE
pwelter34
This fixes a few issues that are causing inconsistent behaviour between field-level and whole-model validation.
See #204 for more context and a demo project
Summary of changes:
EditContext.Modelis used to locate a validator for field-level validation if one is not providedFieldIdentifieris converted to a Fluent property path (egCustomer.Address[0].Line1) by searching theEditContext.Modelinstance, and then the validation results at that path are used to determine if the field is valid. The<FluentValidationValidator>options are supplied to Fluent, but are combined with an additional restriction so that only rules affecting the changed property are ran (as per the defaultMemberNameValidatorSelectorbehaviour)<FluentValidationValidator>that is currently used for whole-model validation is also used when validating fields, this means that RuleSets and other configuration work as expected at the field-level.The above would just mirror the existing whole-model validation for field-level validation, so I think it's a fairly safe change. If a project is using Blazored.FluentValidation then they'll have a validator configured that works for the whole model.
Could I please get your thoughts? I'm looking at this through quite a narrow lense so there may be issues with the proposal that haven't occured to me - it does seem to work okay though.
Resolves #204 Resolves #188 Resolves #180