![]() Public override string GetErrorMessage(ModelValidationContextBase validationContext) All those adapters do is just generate error message based on available metadata: public class StringLengthAttributeAdapter. Let's go further - particular adapter is also created based on what kind of data annotation attribute is being validated (, , etc): var adapter = _validationAttributeAdapterProvider.GetAttributeAdapter(attribute, stringLocalizer) Īgain - there is just a information of attribute itself (with no metadata information about property itself on which attribute is being placed) and previously generated string localizer - which is created only based on container type (model class).Īnd all of the actual data annotation attribute adapters who are responsible for actually generating the error message in case of emergency - has no info about property on which validation attribute is set. String localizer is created based on just container type (actual class within which property is validated). StringLocalizer = _(Ĭ ? ,Īs you can see - there is no metadata available for which actually property is going to be localized. ![]() Pass the root model type(container type) if it is non null, else pass the model type. When provider is asked to create a validator for given validator context (when particular model is being validated or validation attributes being generated on client-side) - validator provider is creating IStringLocalizer instance based on model type alone: // This will pass first non-null type (either containerType or modelType) to delegate. So what's wrong with built-in provider and why I can't just use it out of the box? NumericClientModelValidatorProvider - something special about float, double and decimal validators.DataAnnotationsClientModelValidatorProvider - data annotation attributes driven validation provider.DefaultClientModelValidatorProvider - this is default implementation of the interface and provides validators in model validators metadata.There are 3 providers registered by default: List of client model validator providers are stored in MvcViewOptions.ClientModelValidatorProviders collection. This type is finally responsible for registered client model validation providers: .Internal.MvcViewOptionsSetup. ![]() However, this is just how the localization features are registered within Mvc pipeline and where resources are stored.Ĭlient model validation providers are registered as part of services.AddMvc() call usually found in Startup.cs and later in builder.AddViews() to be more precise, further down in builder.AddViewServices(). More info can be found here so I will not go deeper on this topic. resx files within the assembly and look for the resource based on resource key. However ResourceManagerStringLocalizer is just a wrapper class around which is responsible to keep track of available embedded. Which is essentially just a shortcut for ResourceManagerStringLocalizer creation based on given model type. Simply the following lambda is being registered for this purpose: (modelType, factory) => factory.Create(modelType) Public Func DataAnnotationLocalizerProvider This type is responsible for holding the reference to a factory method for creating new string localizers ( IStringLocalizer): public class MvcDataAnnotationsLocalizationOptions Somewhere along the lines will be registration for MvcDataAnnotationsLocalizationOptions type. So, when you would like to use default built-in provider to localize models via data annotations attributes (required, string length, etc.) this is done by configuring data annotation localization options ( Startup.cs): public void ConfigureServices(IServiceCollection services) That surprised me and I needed to look inside what's going on when Asp.Net Core Mvc is generating markup and trying to figure out what and how to generate client model validation messages. Which looks OK from first sight, but when you change associated resource for required attribute in AdminUI, changed text for that resources is not reflected back to generated markup. Issue described that text from or any other validation attribute was rendered in resulting markup and localization provider was not even involved. But localization provider is not so great when data- attributes are generated. Story begins with small issue registered in GitHub telling that LocalizationProvider does its job excellent when model is submitted to the server and validated there.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |