FluentValidation. Contextual validators - asp.net-mvc

Question

Suppose the following situation:
// [Validator(typeof(AddressForSupplierValidator))] <-- Cannot put both
// [Validator(typeof(AddressForCompanyValidator))] <--
// But even if I skip both of them it works great for SERVER SIDE
public class Address
{
public string AddressName { get; set; }
public string StreetName { get; set; }
}
[Validator(typeof(SupplierValidator))]
public class Supplier
{
public string Name { get; set; }
public Address Address { get; set; }
}
public class SupplierValidator: AbstractValidator<Supplier>
{
public SupplierValidator() {
RuleFor(x => x.Name).NotEmpty();
RuleFor(x => x.Address).SetValidator(new AddressForSupplierValidator());
// AddressForSupplierValidator - Requires AddressName to be .NotEmpty()
}
}
[Validator(typeof(CompanyValidator))]
public class Company
{
public string Name { get; set; }
public Address Address { get; set; }
}
public class CompanyValidator: AbstractValidator<Company>
{
public CompanyValidator() {
RuleFor(x => x.Name).NotEmpty();
RuleFor(x => x.Address).SetValidator(new AddressForCompanyValidator());
// AddressForCompanyValidator - Requires StreetName to be .NotEmpty()
}
}
As illustrated Address entity is being used by Company and by Supplier.
Now I need to validate Address depending on its context.
The above solution works for SERVER SIDE only. But for CLIENT SIDE:
It doesn't generate data-val- attributes on HTML elements. This is
because it lacks any [Validator(..)] on top Address class
definition. Adding [Validator(..)] solves the data-val- generation
but breaks the ideea of reusing Address entity and validate it
depending on context
Questions:
Why the absence of [Validator()] ontop of Address breaks CLIENT SIDE validaton, even with .SetValidator()?
Why do we need RuleFor(x => x.Address).SetValidator(..); if anyway the validator must be specified on top of the class ?
Some thoughts:
My belief is that specifying .SetValidator(..) for a nested property should be enough. The requirement with adding [Validator()] breaks the ideea of reusing same ViewModel with many validation rules depending on context.
The author already did great job integrating the client validation. And they work if leaving the ideea of reusing the viewmodel.
Temporary solution:
public class AddressBase
{
public string AddressName { get; set;}
public string StreetName { get; set;}
}
[Validator(typeof(AddressForSupplierValidator))]
public class SupplierAddress : AddressBase
{}
[Validator(typeof(AddressForCompanyValidator))]
public class CompanyAddress : AddressBase
{}
It works, but again whats the reason for .SetValidator(new AddressForSupplierValidator()); then !? Kind of redundant.
References:
Related SO question which demonstrates this issue is place at:
Unobtrusive client validation data attributes are not rendered for nested property rules